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ABSTRACT 


This  thssis  const dsrs  ths  dssign  and  usas  of  a  data 
dictionary  within  ths  FOCUS  DBMS  packags.  Ths  thssis 
dstails  ths  background  and  dssign  const dsr at ions  of  an 
application  program  for  ths  Dirsctor  of  Admissions  at  ths 
Naval  Postgraduats  School.  Ths  program  will  aid  in  ths 
assignmsnt  of  an  Acadsmic  Profils  Cods  (APC)  for  nswly 
commissi onsd  Naval  Officsrs.  A  data  dictionary  is  dssignsd 
and  implsmsntsd,  and  its  uss  during  application  program 
developmsnt  is  discusssd.  Fsaturss  from  commsrcial  DBMSs, 
fourth  gsnsration  languagss,  and  data  dictionariss  ars 
comparsd  and  thsir  impact  on  information  systsms  considsrsd. 
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ASSIGNMENT  OF  ACADEMIC  PROFILE  CODES  AT  THE  NAVAL 


POSTGRADUATE  SCHOOL 


A.  BACKGROUND 


At  tha  Naval  Postgraduata  School  (NPS) ,  tha  Diractor  oi 
Adfliiasions  is  taskad  with  avaluating  evary  nawly 
commisaioned  Naval  0-f-ficer  concarning  eligibility  -for 


postgraduate  education. 


The  evaluation  process  uses 


in-formation  contained  in  undergraduate  transcripts  to 
compute  a  quality  point  rating  (QPR) .  In  addition,  course 
subject  areas  are  considered  be-fore  the  assignment  of  an 
academic  profile  code  (APC) .  Approximately  3000-5000 
transcripts  are  processed  annually  by  hand. 

The  APC  is  a  three  digit  code  that  reflects  an 
individual's  QPR  as  well  as  background  in  specific 
mathematical  and  scientific  areas.  The  first  digit  of  the 
APC  is  derived  from  Table  I.  The  second  digit  is  the 
mathematics  code  and  is  based  on  the  criteria  in  Table  II. 
The  third  digit  is  the  science/engineering  code  and  is  based 
on  information  in  Table  III. 

The  Director  of  Admissions  at  NPS  feels  that  the  APC 
system  is  a  good  representation  of  a  student's  technical 
ability,  but  does  not  adequately  consider  non-techni cal 


TABLE  I 


I  I 


1 

FIRST  DIGIT  OF 

AN  APC 

1 

1 

CODE 

1 

QPR  RANGE 

1 

1 

I 

1 

0 

i 

( 

3.60-4.00 

{ 

1 

1 

1 

1 

;  • 

3.20-3.59 

\ 

s 

2 

1 

2.60-3. 19 

1 

i 

3 

1 

2.20-2.59 

1 

1 

4 

1 

1.90-2. 19 

1 

1 

1 

a. - 

S 

1 

I 

0-1.09 

1 

1 

- + 

subject  areas.  It  is  conceivable  that  a  -fourth  digit  might 
be  added  that  re-flects  non-technical  performance. 


B.  OBJECTIVE 

FOCUS  has  been  selected  as  the  Data  Base  Management 
System  (DBMS)  for  NFS.  It  is  the  objective  of  this  thesis 
to  discuss  the  design  of  a  FOCUS  data  dictionary  and 
evaluate  its  use  during  the  development  of  an  application 
program  to  aid  in  the  assignment  of  APCs. 


I  C.  METHODOLOGY 

Despite  the  fact  that  the  DBMS  for  this  application 
I  was  chosen  in  advance,  this  thesis  will  compare  data  base 

models  and  explore  features  from  numerous  commercial 
systems.  It  will  also  look  at  the  concept  of  dependent  and 

! 


1 


ind»p«nd«nt  data  dictionarias.  A  basic  data  dictionary  will 
ba  daaignad  and  iaplefflentad  to  aid  in  tha  davalopmant  of 


TABLE  II 

SECOND  DIGIT  OF  AN  APC 

CODE  i 

MEANING 

0 

1 

1 

1 

Significant  post-calculus  math 
with  B  or  better  average 

1 

1 

1 

» 

Calculus  sequence  completed 
with  B-t-  or  batter  average 

2 

J 

1 

1 

Calculus  sequence  completed 
with  average  between  C-*-  and  B 

3 

1 

• 

1 

1 

1 

1 

Two  or  more  pre-calculus 
courses  with  B  or  better 
average  or  one  calculus  course 
with  C  or  better  grade 

4 

1 

J 

1 

1 

Two  or  more  pre-calculus 
courses  with  average  between 

B-  and  C+ 

5 

1 

1 

1 

1 

One  pre-ral cuius  course  with  C 
or  better  grade 

6 

1 

\ 

1 

1 

No  college-level  math  with  C 
or  better  grade 

FOCUS  applications.  Design  considerations,  within  tha  FOCUS 


environment,  are  identified  for  the  dictionary  and  APC 


application  program.  An  svaluation  of  th«  uaafulnvsa  of  a 
dapandant  data  dictionary  during  ayatam  daaign  will  ba  mada. 


1 

1 

TABLE  III 

1 

1 

1 

THIRD  DIGIT  OF  AN  ARC 

1 

1 

1 

CODE 

« 

MEANING 

1 

i 

1 

1 

1 

1 

0 

I 

J 

1 

1 

Significant  uppar 
technical  couraea 
batter  average 

1 

diviaion  1 

with  B+  or  1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

» 

J 

Significant  uppar 
technical  couraea 
between  C-*-  and  B 

1 

diviaion  t 

with  average! 

1 

1 

1 

1 

1 

1 

2 

1 

1 

1 

1 

1 

Completed  calculua-baaed  1 
phyaica  aequence  with  B*  or  1 
better  average  1 

1 

I 

1 

1 

1 

3 

1 

1 

1 

1 

1 

Completed  calculua-baaed  I 
phyaica  aequence  with  average  1 
between  C-t-  and  B  1 

) 

1 

1 

4 

1 

1 

\ 

1 

One  calculua-baaed  phyaica  1 

courae  with  C  or  better  grade  1 

1 

1 

1 

1 

5 

I 

1 

No  pertinent  technical  couraea 1 
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II.  DIRECTOR  OF  ADMISSIONS  OFFICE 


A.  NATURE  OF  THE  PROBLEM 

>  . 

Th«  majority  oi  undmrgraduata  transcripts  corns  -from  ths 
Naval  Acadsmy  and  a  hand-ful  of  NROTC  Uni vsrsi ties.  Ths 
remainder  come  from  colleges  and  universities  all  around  the 
United  States.  Since  there  is  no  standard  transcript 
format,  it  is  necessary  that  each  one  be  reviewed,  and 
pertinent  information  summarized  to  assign  an  APC. 

Currently,  ths  Director  of  Admissions  at  NPS  is 
calculating  QPRs  manually  and  assigning  APCs  based  on  hard 
copy  transcripts.  Considering  ths  number  of  transcripts 
submitted  every  year,  this  process  is  not  only  time 
consuming,  but  costly  and  error  prone. 

The  Naval  Academy  has  agreed  to  provide  NPS  with 
approximately  one  thousand  undergraduate  transcripts 
annually  via  computer  tape.  If  this  one  input  were 
partially  automated,  it  could  result  in  a  twenty  to  thirty 
percent  reduction  in  workload  associated  with  the  assignment 
of  APCs. 

The  tape  co.isists  of  transcripts  sorted  by  student  ID  in 
ascending  order.  An  example  of  records  contained  on  the 
tape  is  shown  in  Table  IV.  The  individual  records  are 
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TABLE  IV 


1-6  courma  naflia 


7-  8  coursa  grada 
9-11  aamaatar  takan 

Soma  apacial  codas  ara  usad  throughout  tha  fila  to  aid 
in  transaction  procadsing.  Tha  grada  fiald  usas  "V"  and  “R" 
as  spacial  codas  to  indicata  coursas  validatad  or  rapaatad 
raspacti valy.  Valid  antrias  for  lattar  gradas  in  tha  grada 
fiald  ara  listad  in  Tabla  V. 

Additionally,  tha  Naval  Acadamy  will  provida  a  computar 
tapa  listing  of  coursa  namas  and  cradit  hours  assoc iatad. 
Coursa  namas,  gradas,  and  cradit  hours  ara  raquirad  to 
calculata  a  QPR  for  aach  graduata.  An  ax amp la  of  tha 
listing,  sortad  by  coursa  nama  in  ascanding  ordar  (A-Z,0-9), 
is  shown  in  Tabla  VI. 

Most  undargraduata  uni  varsi '^ias  calculata  a  Quality 
Point  Rating  in  tha  sama  mannar.  Navarthalass,  two  problams 
arisa  whan  a  QPR  calculatad  by  an  out si  da  sourca  is  usad  by 
NP8  to  assign  an  APC.  Tha  most  straightforward  of  tha  two 
is  tha  convarsion  from  tha  thraa  point  to  tha  four  point 
seal  a.  This  is  not  tha  casa  with  tha  Naval  Acadamy,  hanca 
tha  solution  will  not  ba  discussad  in  this  thasis.  On  tha 
qualitativa  si  da,  if  an  undargraduata  studant  rapaats  a 
coursa  and  racaivas  a  highar  grada,  only  tha  highar  grada 
goas  into  tha  calculation  of  a  QPR.  If  this  fact  wars 
ignorad  in  tha  assignmant  of  an  APC,  it  could  maan  that  a 


TABLE  V 


+- 

I 

I 

I 


VALID  LETTER  GRADES 


NORMAL 


VALIDATE  ** 


I 


I  REPEATED  COURSE*  I 


*  ua*d  in  OPR  calculations  «*  not  usod  in  OPR  calculations 


^ - - - 

— t 

t 

TABLE  VI 

1 

1 

1 

1 

COURSE  CREDIT 

HOURS 

1 

1 

1 

IEA303,2 

EE221,4 

EE494,2 

FE301,3 

FP314,3 

1 

1 

IHEill,3 

HE442,3 

HH224,3 

HH362,3 

N8101t,3 

1 

l8H20i,4 

1  - 

80471,3 

8P440,3 

SP493,2 

8R401,3 

1 

1  _ _ _ 

1 

J  J  M  J  _l 

1 

1 

1 

*  indicitt*  courtti  uiad  in  Hilit«ry  OPR  calculation 


student  who  repeated  a  course  to  receive  a  passing  grads 
could  be  assigned  the  same  APC  as  a  student  who  easily 
completed  the  course  initially.  This  is  not  the  intention 
of  the  APC.  To  preclude  this  possibility,  all  undergraduate 
QPR's  are  recalculated  by  the  Director  of  Admissions  at  NPS. 
The  new  QPR  includes  all  grades  received  by  a  student,  and 
in  a  sense  becomes  a  common  denominator  for  academic 


evaluation 


B.  SYSTEM  REQUIREMENTS 


On«  formal  raport,  ahown  in  Figura  2.1,  dictatas  all 
ayatam  raquiramanta.  NFS  Form  S040/2  (raviaad  12/81), 
Acadamic  Racord  Evaluation  ia  a  tranacript  aummary  that 
facilitataa  tha  aaai^nmant  of  an  AFC.  It  ia  alao  uaad  by 
tha  Dapartmant  Chairman  to  aid  in  a  aubjactiva  Judgmant  on 
whathar  an  individual 'a  acadamic  background  will  aupport  a 
apacific  maatara  program.  Tha  quariaa  requirad  to  complata 
Form  5040/2  ara  liatad  balow. 

1.  Count  tha  number  of  couraaa  in  aach  aubjact  araa  by 
1  attar  grade. 

2.  Calculate  a  QFR  baaed  on  valid  letter  grade  and  courea 
credit  hour  entriaa. 

Before  tha  daaign  of  tha  application  program  daacribad 
above,  a  data  dictionary  waa  implamantad  to  aid  in  program 
development.  Tha  raquiramanta  and  daaign  apacif icationa  for 
tha  data  dictionary  ara  diacuaaad  in  Chapter  4. 


The  daciaion 

to 

purchaaa 

and 

uaa  FOCUS 

aa 

the 

adminiatrati va  DBMS 

for 

NFS  waa 

made 

primari ly 

by 

tha 

Admiaaiona  Office  programming  ataff.  Their  choice  waa 
heavily  influenced  by  programming  capabilitiaa  and  a  modular 
pricing  policy.  Baaic  FOCUS,  excluding  optiona  like 
financial  modeling  and  graphica,  can  be  purchaaad  for  leaa 
than  many  other  mainframe  ayatama.  Navarthalaaa,  it  ia 
important  that  policy  and  daciaion  makara  be  involved  in  the 


ACADEMIC  AECOFIO  EVALUATION 

NPt  S040/9  (12-ail 


Year  Group 


Figure  2 . 1  Academic  Record  Evaluation  Form 


sp«cif ication  of  system  capabilities.  A  problem  arises  when 
management  is  unfamiliar  with  common  DBMS  attributes.  It  is 
di-^ficult  to  specify  requirements  without  being  familiar 
with  capabilities. 

Chapters  3  and  4  are  intended  to  provide  management  with 

>  . 

a  background  and  understanding  of  the  capabilities  of 
current  DBMSs  and  data  dictionaries.  A  better  understanding 
should  allow  managers,  users,  and  programmers  to  take 
advantage  of  the  fourth  generation  environment  provided  by 


FOCUS 


III.  DATA  BASE  MANAGEMENT  SYSTEMS  AND  FOURTH 
GENERATION  LANGUAGES 

A.  COMPARISON  OF  DATA  BASE  MODELS 

f 

Bc-fora  an  attempt  can  ba  mada  to  understand,  design, 
implement,  or  simply  use  a  DBMS,  a  data  model  is  needed.  In 
addition,  not  all  people  think  alike,  so  that  different 
approaches  may  appeal  to  different  people.  Hence,  different 
data  models  may  be  needed. 

The  selection  of  a  DBMS  should  be  heavily  influenced  by 
the  data  models  and  resulting  logical  views  of  data 
provided.  FOCUS  is  primarily  based  on  the  hierarchical  data 
model.  It  should  be  determined  in  advance  that  data 
structures,  intended  applications,  and  users  are  compatible 
with  the  capabilities  and  limitations  of  the  data  model.  If 
they  are,  a  DBMS  that  implements  that  model  would  be  a  good 
choice. 

If  the  underlying  data  model  for  a  DBMS  is  not 
considered  before  implementation,  there  is  a  chance  that 
data  may  have  to  be  forced  into  incompatible  logical 
structures  to  conform  with  data  model  limitations.  The 
Administration  at  NPS  should  be  aware  of  the  strengths  and 
weaknesses  of  the  data  model  underlying  FOCUS  and  the 
available  alternatives. 


Ovar  tha  paat  tan  yaara*  no  -fawar  than  twanty  data 
modal  a  hava  baan  propoaed.  Each  haa  ita  own  concapta  and 
tarminology.  Thara  ara  thraa  major  model  a  currently 
implemented  by  commercial  ayatama.  The  following  aactiona 
provide  an  overview  of  the  CODASYL,  Hierarchical,  and 

f 

Relational  data  modala  aa  daacribad  by  CRaf.  1,21. 

1 .  CODASYL 


The 

words 

schema  and 

subschema 

were 

first 

highlighted 

in  1969, 

by  the  CODASYL 

Data  Base 

Task 

Group 

(DBTQ) ,  to 

describe 

different  views 

of  data. 

It  was  the 

concept  of 

a  common 

Data  Description  Language 

(DDL) 

that 

gave  rise 

to  three 

specific  views 

of  datai 

the 

global 

conceptual  view  or  achama,  the  axtarnal  or  aubachama  view, 
and  the  internal  view  or  phyaical  data  baaa  daacription. 

The  achema  is  the  complete,  logical  view  of  the 
database,  and  subschamaa  ara  subsets  of  schemas  aa  viewed  by 
application  programmers.  Not  all  records  or  relationships 
of  a  schema  are  exposed  to  subschemas,  but  when  included  in 
a  subschema,  they  can  be  renamed  and  data-item  formats  can 
be  changed. 

To  aid  in  the  separation  of  physical  and  logical 
views  of  the  database,  the  schema  does  not  contain  the 
physical  description  of  the  database.  The  Data  Structure 
Definition  (DSD)  is  used  to  map  physical  storage 
requirements  and  to  specify  access  methods. 


The  C0DA8YL  model  is  •  physicsl  dstsbsse  model  that 
makes  use  of  dats-i terns,  records,  and  a  relationship  called 
a  set.  A  set  consists  of  a  two-level  tree  of  records.  Each 
set  type  can  represent  a  relationship  between  two  or  more 
record  types.  Each  set  must  contain  one  occurrence  of  its 
owner  record  and  may  contain  any  number  of  member  records 
(one-to-many) .  Figure  3.1  gives  an  example  of  a  C0DA8YL 
set. 

A  multilevel  hierarchical  file  or  simple  network  can 
be  regarded  as  being  composed  of  multiple  sets.  Each 
one-to-many  relationship  is  Just  replaced  by  a  set.  An 
early  criticism  of  the  DBTO  proposed  DML  was  its  inability 
to  describe  complex  pi  ex  structures  also  known  as  networks. 
This  is  not  necessarily  a  serious  disadvantage  because  the 
complex  structures  can  be  decomposed  to  simple  networks  by 
defining  intersection  records.  What  does  suffer,  however, 
is  the  logical  view  of  the  data. 

The  C0DA8YL  Task  Oroup  also  addressed  important 
topics  such  as  logical  and  physical  independence  vs. 
response  time  and  data  integrity.  The  implementation  of 
areas  was  a  compromise  between  too  much  physical  control 
which  destroys  data  independence  and  too  little  physical 
control  which  sacrifices  response  time.  An  area  is  a  named 
subdivision  of  a  database.  They  are  intended  for  use  by  the 
DBA  to  enhance  system  efficiency  through  control  of  record 


placement . 


I  record  type-i 


;  MEMBER  RECORDS 


I  record  type-2  I  + 

+ - +  I  + 


I  record  type-3 1  + 

+ - +1  + 


Figure  3.1  Example  ot  a  CODRSYL  Set 


The  COOASYL  model  addressed  data  protection  by 
implementing  privacy  locks.  These  locks  are  Imposed  at  any 
level  in  the  system  from  the  overall  schema  to  an  individual 
data  item.  Without  the  proper  key,  similar  to  a  password, 
the  update/modi f y  type  functions  can  be  inhibited. 

When  the  notion  of  a  standard  began  to  gain 
support,  so  did  the  controversy  over  what  the  standard 
should  be.  IBM's  Data  Language/I,  a  hierarchical  based 
language,  along  with  proposed  relational  systems  began  to 
challenge  CODASYL  for  the  title  of  industry  standard. 


2.  Hierarchical 


IBM  began  the  development  of  Data  Language/ I  (DL/I) 


in  the  1960 's  to  support  the  aerospace  industry 


It  is 


still  ths  basis  -for  thsir  DBMS  called  Information  Management 


System  (IMS). 

In  DL/I,  a  field  is  the  smallest  unit  of  data.  A 
group  of  fields  is  known  as  a  segment  and  a  hierarchically 
structured  group  of  segments  constitutes  a  data  base  record. 
Each  relationship  between  records  is  one-to-many  with  all 
arcs  pointing  toward  the  leaves.  At  this  point,  the 
similarities  between  the  CODASYL  logical  set  and  DL/I 
hierarchical  structure  can  be  seen.  Figure  3.1  could  be 
relabeled  and  used  for  the  hierarchical  model.  As  a  result 
of  this  similar  tree  structure,  DL/I  must  transform  network 
relationships  into  hierarchical  form  in  much  the  same  way  as 
the  CODASYL  sets.  The  network  is  first  decomposed  into 
trees  with  duplication,  and  then  logical  pointers  are  used 
to  remove  the  redundancy.  These  logical  child  pointers  make 
it  possible  to  represent  multiple  logical  structures  from 
any  number  of  physical  trees.  Figure  3.2  gives  an  example 
of  the  process. 

The  three  views  of  data  described  earlier,  are  not 
supported  by  DL/I  or  the  FOCUS  Data  Description  Language. 
The  only  distinction  made  is  between  logical  and  physical 
data  base  records.  A  logical  data  base  may  be  either  a 
subset  of  a  physical  data  base,  or  it  may  contain  parts  of 
two  or  more  physical  data  bases.  Segment  relationships  can 
be  present  in  the  logical  structure  that  do  not  exist  in  the 


physical  data  base 
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Flgur*  3.2  '  Dvcomposition  of  •  CompleK  Network 


Sensitivity  is  «  term  used  to  describe  the  ability 
of  application  programmers  to  maintain  separate  views  of  the 
same  data  base.  Application  programs  are  sensitive  only  to 
changes  made  in  the  physical  data  base  that  are  reflected  in 
their  logical  view.  In  some  cases,  the  physical  data  base 
may  be  modified  without  changing  application  programs.  In 
other  words,  the  logical  view  is  insensitive  to  unrelated 
changes  in  the  physical  data  base.  The  separation  of 


logical  and  physical  visws  is  an  important  stsp  toward  data 
indspondsncs. 

3.  Rslational 

Dr.  E.  F.  Codd  first  introduced  the  relational  model 

>  . 

in  1970  CRef.  33.  As  early  as  1975,  this  model  was  being 
heralded  as  the  key  to  further  automation  in  database 
management  software.  Nevertheless,  it  was  not  until  the 
early  1980's  that  a  commercially  viable  relational  DBMS  was 
available.  The  first  was  IBM's  SQL/DS,  followed  closely  by 
ORACLE  from  Relational  Software  Inc.  Both  systems  use 
Structured  Query  Language  <SQL)  for  query,  data 
manipulation,  and  data  definition. 

The  relational  model  is  unique  in  that  it  is  used 
only  for  the  logical  description  of  data.  A  relational 
database  can  be  physically  structured  many  different  ways. 
No  knowledge  of  the  underlying  data  structures  such  as 
linked  or  inverted  lists  is  required.  Physically  oriented 
models  can  inhibit  changes  to  data  that  may  be  needed  as  the 
database  grows,  because  the  changes  would  dictate  expensive 
application  program  modification. 

Two-dimensional  flat  files,  called  relations,  are 
used  to  represent  data  in  the  relational  model.  Columns  are 
called  attributes  and  rows  are  called  tuples.  Each 

attribute  must  have  a  unique  name  and  a  domain,  the  set  of 
values  that  the  attribute  can  have.  A  tuple  is  said  to  be 


of  d«gm  n,  whvra  n  im  tho  numbor  of  attributos.  No  two 
tuplos  in  a  relation  can  be  identical  and  their  order  is 


insignificant.  The  generalized  form  of  a  relation  and 
several  occurrences  are  depicted  in  Figure  3.3. 


STUDENT 

STUDENT (ID#,  name, 

RELATION 

age ,  sex 

,  major) 

1  I 

747231 

1  SMITH 

1 

18 

1  M 

EE  1 

1  1 

747233 

1  JONES 

1 

17 

1  F 

EN0  1 

i  1 

747722 

1  MADISON 

1 

17 

1  F 

PHY  1 

1  1 
! 

744345 

1  JOHNSTON 

1 

18 

1  M 

MTH  1 

Figure  3.3  Example  of  Relational  Flat  Files 


To  insure  a  flexible  and  consistent  logical 
representation,  Codd  designed  a  technique  called 
normalization.  First  normal  form  involves  the  elimination 
of  repeating  groups  by  specifying  that  each  attribute  must 
be  a  fact  about  the  key.  Second  normal  form  reduces 
redundancy  by  insuring  that  every  non-key  field  is  a  fact 
about  the  entire  key.  Third  normal  form  eliminates  deletion 
anomalies  by  specifying  that  a  non-key  field  cannot  be  a 
fact  about  any  other  non-key  field.  With  normalization  and 


intorrssction  records,  any  representation  can  be  reduced  to 
two-dimensional  -flat  files  with  some  redundancy. 

To  provide  a  subschema  that  is  logically  separate 
from  the  physical  database,  it  is  necessary  to  be  able  to 
extract  subsets  of  rows  and  columns  from  the  relations  that 
make  up  the  schema.  The  name  used  to  describe  this 
manipulation  of  relations  is  relational  algebra.  Using 
relational  algebra,  operators  are  defined  that  work  on 
relations.  The  practical  use  of  relational  algebra  is 
seldom  seen  because  of  its  procedural  structure,  but  the 
underlying  concepts  are  important. 

The  advantage  of  a  nonprocedural  language  is  that 
the  user  specifies  what  is  required,  possibly  in 
English-like  terms,  and  the  system  can  optimise  how  to 
obtain  the  required  data.  Nonprocedural  language  interfaces 
have  taken  many  forms.  For  example,  SQL  is  a  nonprocedural 
transf er-ori ented  language  that  is  capable  of  using 
relations  to  transfer  data  into  results. 

The  relational  model  is  the  most  widely  accepted  and 
adopted  in  commercial  applications  today.  The  individual 
reasons  vary  from  its  mathematical  basis  to  its  logical 
structure.  The  bottom  line  is  that  the  user,  whether  casual 
or  experienced  programmer,  can  understand  and  maintain  the 
resulting  logical  structure  much  more  easily  than  with  the 
previously  described  models. 
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In  «  mmall  databas*,  with  minor  appl icationa,  thmrm 
may  bm  no  advantagm  for  relational  over  network  or 
hierarchical.  However,  ae  the  database  grows  and  data  and 
relationships  are  added  and  changed,  a  properly  designed 

relational  system  often  is  much  simpler  and  less  SKpensive 

> , 

to  maintain.  Good  data  independence  and  normalized  form 
will  usually  allow  growth  and  change  in  the  database  without 
forcing  the  rewriting  of  application  programs.  Without 
these  characteristics,  the  cost  of  maintaining  an 
organization's  programs  and  data  can  quickly  rise  to  an 
unacceptable  level. 

B.  FOURTH  GENERATION  LANGUAGES 

NP8  is  still  new  to  the  data  base  environment  and 
already  a  programming  backlog  has  developed.  The  delay  for 
non-trivial  applications  can  exceed  six  months.  Possible 
solutions  include  hiring  more  programmers,  increasing 
existing  programmer  productivity,  and  involving  users  in 
application  proggram  development.  The  fourth  generation 
environment  provided  by  FOCUS  is  capable  of  increasing 
productivity  and  involving  users. 

The  evolution  of  computer  languages  has  occurred  in 
distinct  stages.  Machine  language,  patterns  of  ones  and 


zeros,  was  the  first  followed  by  second  generation  assembly 
language  which  used  symbols  and  mnemonics  to  replace  the 


p«ttarns  oi  zaroa  and  onaa.  Third  ganaratlon,  high-laval 
procadural  languagaa  auch  aa  COBOL,  FORTRAN,  and  Paacal  wara 
naxt  to  avolva.  With  aach  ataga  in  tha  davalopmant  of 
huflian-computar  communication,  tha  programmar  waa  raquirad  to 
know  laaa  about  tha  phyaical  compoaition  of  data  atructuraa. 

Tha  concapt  of  data  indapandanca,  whara  tha  programmar 
ia  not  concarnad  with  tha  atructura  of  data,  waa  an  aarly 
goal  of  data  baaa  daaignara.  It  waa  not  until  tha  advant  of 
tha  ralational  data  baaa  that  thia  goal  waa  raalizad.  Aa  a 
raault  of  ita  data  indapandant  daaign,  tha  ralational  data 
baaa  facilitatad  prograaaion  to  tha  naxt  ataga  in  computar 
languaga  davalopmant,  tha  fourth  ganaration  languaga  (4GL) . 
Richard  Cobb,  ona  of  tha  davalopara  of  tha  firat  4GL  aaid, 
"In  fact,  withoutO  atructure-indapandant  DBMSa,  fourth 
ganaration  languagaa  would  navar  hava  coma  into  axiatanca. " 
CRaf.  4ip.  921 

Thera  are  two  main  differancaa  between  third  and  fourth 
generation  languagaa.  Firat,  the  number  of  programmed 
inatructiona  ia  typically  laaa  when  4GLa  are  uaed.  But,  it 
ia  the  nonprocedural  atructura  of  4GLa  that  make  them 
unique.  A  uaar  tel  la  tha  computer  what  ha  wanta  rather  than 
how  to  ratriava  it.  Thia  landa  itaalf  eaaily  to 
Engliah-lika  command  atructuraa. 

Productivity  ia  the  focua  of  moat  compariaona  between 
third  and  fourth  generation  languagaa.  Tha  tendency  ia  to 
perform  aome  quantitative  analyaia,  baaed  on  hiatorical  and 


projcctad  programmar  productivity,  to  support  ths  transition 
to  -fourth  gensration  opsrations.  Richard  Cobb,  dsvslopsr  of 
Ramis  II,  computsd  a  savings  of  approx imatsly  #1,000,000 
with  a  4GL  versus  only  #23,000  with  a  3GL.  Very  little 
effort  was  devoted  to  Justifying  the  remaining  4GL  benefits. 
The  most  important  is  that  it  is  easily  used  by  both 
computer  specialists  and  end  users.  CRef.  4ipp.  91-973. 

Very  few  people  dispute  the  increase  in  individual 
programmer  productivity  with  4GLs,  although  some  have  been 
quick  to  point  out  other  weaknesses,  such  as  the  lack  of  an 
industry  standard.  The  development  of  computer  software  is 
moving  so  quickly  that  it  is  difficult,  at  times,  to 
determine  which  advance  is  a  step  and  which  is  a  landing. 
For  that  matter,  it  is  hard  to  tell  which  development  is  an 
advance.  Claims  that  organizational  productivity  bog  down 
because  of  the  impact  of  a  4GL  product  on  the  existing 
environment  is  more  than  likely  a  result  of  the  environment 
and  not  the  4GL.  Without  question,  systems  and 
organizations  will  have  to  change  to  take  advantage  of 
fourth  generation  application  development  capabilities.  It 
is  not  unusual  for  technology  to  dictate  change. 
Organizations  that  do  not  change,  but  rely  on  technology 
alone  to  increase  their  overall  productivity,  may  be 
disappointed  with  4GLs.  CRef.  5ipp.  99-1043 
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C.  COMMERCIAL  DATA  BASE  MANAGEMENT  SYSTEMS 


Thar*  arv  dozanm  of  cominarcial ly  available  Data  Baee 
Management  Syetems.  Each  one  has  relative  strengths  and 
weaknesses.  It  is  up  to  the  system  designer  to  determine 
requirements,  evaluate  the  available  systems,  assess  future 
trends,  and  select  the  most  appropriate. 

Applications  and  systems  designers  may  suffer  from  a 
lack  of  flexibility  in  the  modeling  of  data  relationships 
due  to  constraints  imposed  by  a  particular  DBMS.  They  are 
forced  to  compromise  in  their  selection  of  data  models.  In 
some  cases,  applications  are  so  diverse  that  multiple  data 
models  are  employed,  necessitating  the  use  of  more  than  one 
DBMS. 

According  to  Has  Patel,  Manager  of  Product  Planning  for 
MSP  Inc. ,  the  solution  is  to  plan  an  environment  in  such  a 
way  that  the  DBMS  is  separated  from  the  application  system. 
He  asserts  that  the  emphasis  should  be  placed  on  Logical 
Data  Structure  Designs  (LDSD)  which  are  independent  of 
physical  DBMS  implementations.  This  could  be  accomplished 
with  a  data  dictionary  as  a  tool  for  the  management  and 
control  of  a  corporate  data  resource.  CRef.  6ipp.  86-911 
A  DBMS  should  perform  the  following  functionsi 

*  Define  and  store  the  data  base  structure  using  a  data 
definition  language. 

«  Load  data  into  the  data  base  from  terminals  or  external 
data  files. 
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*  Provld*  a  Mid«  variaty  of  accass  mathods  such  as 

saquantial  and  kayad.  Promota  logical /physical 

indapandanca  by  automatically  updating  tha  physical  data 
basa  Nhan  changas  ara  mada  to  tha  logical  structura. 

*  Provida  multipla  viaws  of  data  dapanding  on  class  of 
user. 

*  Provida  sacurity  faaturas  to  control  accass  to  data 

> 

*  Enabla  control  ovar  concurrant  oparations  to  allow 
raad/writa  accass  to  multipla  usars. 

*  Facilitata  backup  and  racovary  with  rollback  and 
rollforward  utilitias. 

«  Provida  data  manipulation  capabilitias  via  quary 
languaga. 

*  Provida  raport  ganaration  capabilitias. 


To  aid  in  tha  salaction  of  an  appropriata  DBIiS,  short 
summarias  with  applicabla  commants  on  aach  of  twanty-fiva 
commarcial  systems  are  provided  in  tha  next  sections. 
Table  VIII  lists  vendor  information  and  data  modal  basis  for 
a  number  of  popular  DBMSs.  The  ''self-contained"  designation 
in  Table  VIII  signifies  that  tha  DBMS  is  based  on  its  own 
internal  model.  These  self-contained  models  usually 
consist  of  some  combination  of  the  three  major  data  models 
discussed  earlier. 


1 .  Accent  R 


ACCENT  R  is  a  relational  DBMS  marketed  by  National 


Information  Systems,  Inc.  It  is  designed  to  run  on  Digital 
Equipment  Corporation  DEC  system-10/20  under  the  TOPS-10/20 
or  VMS  operating  system. 


TABLE  VII 


DATA  BABE  HANA6ENEMT  BYBTEH8 

OBNS  NAHE 

VENDOR 

NODEL 

Accant  R 

National  Inforaation  Byataaa 
2037(^  Town  Ctr.  Ln.,  Suita  130 
Curpartino,  CA.  95014 

Ralational 

ADABA8 

Softwara  A8 

8alf-Containad 

Condor 

Condor  Coaputar  Corporation 

2031  South  8tata 

Ann  Arbor,  HI.  41804 

Ralational 

Data  Nanagaaant 

IV 

Honaywall  Inforaation  Syttaaa 

CODASYL 

Datacoa/DB 

Appliad  Data  Raaaarch,  Inc. 

Ralational 

Dbaaa  11 

Aahton-Tata 

10150  Jaffaraon  Blvd. 

Culvar  City,  CA.  90230 

Ralational 

BBn8-990 

Taxat  Inttruaantf 

Salf-Containad 

DBN8-Prioo 

Priaa  Coaputar  Incorporatad 

Salf-Containad 

DHB  1100 

Sparry  Coaputar  Syitaaa 

CODASYL 

DH3-170 

Control  Data  Corporation 

CODASYL 

ORB 

Advancad  Data  Nanagaaant 

15-17  Nain  St. 

Kingston,  NY.  08528 

Salf-Containad 

Encoapaai 

Tandoa  Coaputars,  Inc. 

Salf-Containad 

Expraai 

Nanagaaant  Dacision  Systaas 

Ralational 

Focui,  PC/Focui 

Inforaation  Buildars,  Inc. 

1250  Broadway 

Naw  York,  NY.  10001 

Salf-Containad 

IDIS 


Intffl  Corporation 
3063  BoHtrt  Avenua 
Santa  Clara,  CA.  95051 


Ralational 
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DATA  BASE  HANABEHENT  8Y8TEH8  (CONT.) 
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DBAS  NAME 

VENDOR 

HODEL 

IDHS/R 

Cullintt  Software,  Inc. 

400  ^lue  Hill  Dr. 

Meitwood,  Haieachuietti  02090 

Relational 

laagi 

Hewlett  Packard 

19447  Prueerldge  Avenue 
Cupertino,  CA.  9S014 

Network 

IHS 

IBM  Corporation 

Hierarchical 

InTo 

Henco  Software  Inc. 

100  Fifth  Ave. 

Halthae,  HA.  021S4 

Relational 

Ingrit 

Relational  Technology,  Inc. 

28SS  Telegraph  Ave. 

Berkeley,  CA.  94705 

Relational 

Inquirt 

Infodata  Syeteet  Inc. 

5205  Leeiburg  Pike 

Falls  Church,  Virginia  22041 

Self-Contained 

NDB8  I 

I8E-U8A 

85  Nest  Algonquin  Road 

Arlington  Heights,  IL.  60005 

C0DA8YL 

MDBS  III 

ISE-USA 

85  Mest  Algonquin  Road 

Arlington  Heights,  11.  60005 

Self-Contained 

nodtl  204 

Cooputer  Corporation  Of  Aeerica 

4  Caebridge  Center 

Caebridge,  Hassachusetts  02142 

Self-Contained 

Not«d2 

DI(B  Coeputer  Services 

187  Danbury  Road 

Nil  ton,  CT.  06897 

Relational 

Oracle 

Oracle  Corporation 

3000  Sand  Hill  Road 

Nenlo  Park,  CA.  94025 

Relational 

s  A 


•v' 


I 


I 


TABLE  VII 

DATA  BASE  NANA6EHENT  SYSTEMS 

(CONT.) 

DBHS  NAHE 

VENDOR 

MODEL 

Raais  II 

Nathuatica  Product!  Sroup 
P.O.  Box  2392 

Princaton,  Naa  Jartay  08540 

Saif -Containad 

Rapport 

Logica,  Inc. 

3  Eabarcadaro  Cantar 

San  Francitco,  CA.  94111 

Ralational 

Rtlatt/3000 

Coaputar  Raaot  caa,  Inc. 

5333  Batfay  R'  aa  Dr. 

Santa  Clara,  '  1.  95054 

Ralationalal 

Rubix 

Infoayataaa  Tachnology 

6301  Ivy  Lana 

Braanbalt,  HD.  20770 

Ralational 

Said  DBHS 

Said  SoTtaara/Unitad  Talacoa 
2300  Halnut  St.,  Suita  734 
Philidalphia,  PA.  19103 

CODASYL 

SOL/DS 

IBM  Corporation 

Ralational 

Systia  1022 

Softaara  Houaa 

Caabridga,  HA.  02138 

Ralational 

Syataa  2000 

Intal  Syataaa  Corporation 
3065  Boaara  Avanua 

Santa  Clara,  CA.  95051 

Salf-Containad 

Thi  KnoNladgi 
Hanager 

Micro  Data  Baaa  Syataaa,  Inc 
Box  248 

LaTayatta,  IN.  47920 

Ralational 

TIS 

Cincoa  Syataaa,  Inc. 

P.O.  Box  11189 

Cincinnati,  Ohio  45211 

Ralational 

Totil 


Cincoi  Systcat,  Inc. 
P.O.  Box  11189 
Cincinnati,  Ohio  4S211 


SiH-Contained 


are  combined  into  one  independent  index  file.  Records  may 
be  accessed  through  keyed  or  unkeyed  fields  and  RAM  indexes 

provide  fast  keyed  retrieval. 

; 

Data  entry  is  controlled  by  commands  that  allow 
input  to  chosen  fields,  prompting,  duplication  of  values, 
pre-testing  for  errors,  and  validation  based  on  a  data  file. 
Field  names  are  up  to  forty  characters  long  and  are  of  types 
integer,  real,  double  precision,  character,  alpha,  date, 
bit,  and  user  defined. 

Accent  R  provides  a  non-procedural  natural  query 
language,  a  high-level  structured  programming  language,  and 
host  language  interfaces  for  FORTRAN,  COBOL,  and  BASIC. 

The  Data  Base  Library  is  an  actively  maintained 
dictionary.  It  provides  information  about  how  programs  and 
data  are  structured,  processed,  and  related.  It  works  with 
a  utility  named  SOMOD  to  recompile  all  necessary  programs 
when  a  change  is  made. 


2.  Adabas 


Adabas  is  comprised  of  the  Associator  (inverted 
lists,  coupled  lists  and  system  file).  Data  Storage,  and 
Work  Storage  (temp  space).  Numerous  utilities  are  used  to 
load  the  data  base,  add  new  fields,  add  new  paths,  define 
new  relationships,  and  sequence  files  without  resorting. 
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The  data  base  files  are  described  to  the  data  dictionary 
which  contains  information  about  the  characteristics  of  data 
items,  such  as  their  relationship  to  other  items  and  where 
they  are  used. 

A  comprehensive  backup  and  recovery  facility  logs 
all  changes  to  the  data  base  and  writes  coordinated 
checkpoints.  Partially  completed  transactions  are  removed 
and  the  data  base  can  be  restored  to  any  checkpoint  if  a 
failure  occurs. 

Host  language  calls  to  ADABAS  are  embedded  in  COBOL, 
FORTRAN,  PL  1,  and  Assembler.  ADASCRIPT+,  ADACOM,  and 
NATURAL  data  manipulation  languages  are  provided. 

3.  Datacom 

Datacom  is  designed  for  use  with  IBM  mainframe 
equipment  and  operating  systems.  System  utilities  provide 
high-speed  loading,  unloading,  and  recovery.  DATACOM  offers 
complete  transaction  backout,  rol 1 -forward ,  and 
rol 1 -backward  restart  and  recovery  capabilities.  Data  base 
files  may  be  recovered  or  restored  from  any  point  in  time. 

Record  locking  is  automatic  at  the  logical  record 
level.  A  program  may  have  many  records  locked  concurrently. 
Data  contention  situations  are  reported  to  the  user  in  the 
data  base  statistics.  Deadlock  is  detected  and  resolved  by 


the  system. 


A  DATADICTIONARY  facility  dascribaa  tha 
charactariatica  of  data  itama  within  tha  data  baaa.  Thair 
relation  to  other  itama,  applicationa,  and  involvement  in 
the  entire  ayatem  are  alao  included.  Thia  ia  an  active 

dictionary  facility  that  containa  the  control  data  uaed  to 

> 

drive  Datacom. 

Data  manipulation  may  be  accompli ahed  uaing 
appl  cation  programa  written  in  either  COBOL,  PL  1,  ALC, 
FORTRAN,  or  RP0.  A  high  level  language  facility  <ADR/DL)  ia 
available  to  define  and  manipulate  data  uaing  Engl iah-l i ke 
atatementa.  IDEAL  ia  a  aelf -contained  relational 
4th-generation  language.  DATAQUERY  ia  a  aelf -contained 
relational  query  language. 

4.  Dbaae  II 

A  microcomputer  baaed  relational  DBMS,  dBaae  II 
requirea  CP/M  2.2  or  later  for  8  bit  ayatema  or  PC-DOS, 
MS-DOS,  or  CPM  86  for  16  bit  ayatema.  Filea  are  atored  aa 
fixed  length  ASCII  data.  Acceaa  ia  aequential  or  random 
uaing  inverted  B-tree  indexea. 

The  query  language  all  owe  memory  variable  atorag*  to 
be  aaved  to  diak,  and  reatored  later.  Acceaa,  eecurity,  and 
validation  can  alao  be  accompli ahed  through  uae  of  the  query 
language.  The  on-line  environment  allowe  the  uaer  to  acceaa 
any  of  several  records,  edit  them  or  browse  through  the  data 
base.  No  active  dictionary  support  is  currently  available. 


5.  DBMS  -  Prime 


DBMS  -  Prime  is  a  CODASYL  based  system.  It  supports 
CODASYL  DDL,  COBOL,  FORTRAN,  and  CODASYL  DML  commands. 
Sub-schema  compilers  for  FORTRAN  and  COBOL  generate  object 
sub-schema  files  and^a  DML  preprocessor  converts  CODASYL  DML 
statements  to  host  language  calls. 

A  schema  editor  is  available  to  support  revising  the 
schema  in  an  interactive  mode.  The  stored  data  base  is 
automatically  revised  to  correctly  reflect  any  changes  to 
the  schema.  Whenever  a  sub-schema  is  recompiled,  the  system 
insures  that  all  associated  programs  are  recompiled. 

Data  integrity  is  preserved  through  extensive 
failure  protection  procedures.  An  automatic  rollback  to  the 
end  of  the  last  completed  transaction  on  program  failure, 
rollback  utility  on  system  failure,  and  rollforward  utility 
for  system  or  media  failure  are  Just  a  few. 

6.  Data  Manager  IV 

Honeywell  Information  Systems  (HIS)  markets  a 
comprehensive  on-line  CODASYL  based  DBMS  named  DATA  MANAGER 
IV  (DMIV).  As  with  most  CODASYL  implementations,  data  base 
integrity  is  provided  by  before  and  after  images,  rollback 
and  rollforward  functions,  and  checkpointing.  Every 
sub-schema  must  be  validated  against  the  schema  and  a  user 
generated  DML  permitted/prohibited  list. 
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Data  basa  initialization  and  rastructuring  ara 
accompl iahad  through  utilitias.  Initial  and  aubaaquant  data 
loading  ara  via  COBOL  or  FORTRAN  uaar  programa  (no 
praprocaaaor  raquirad).  Any  record  type  may  be  defined  aa 

owner  or  member  in  any  number  of  aata.  Thia  providea 

> 

hierarchical,  tree,  and  network  capabi 1 i tiea.  If  deaired, 
the  entire  data  baae  may  be  viewed  aa  a  relational, 
table-oriented  data  baae.  In  aupport  of  thia,  HIS  providea 
IQ,  EQ,  and  RQ,  three  new  relational  languagea. 

HIS  alao  providea  a  Data  Dictionary/Directory  Syatem 
(DO/DS)  that  supporta  up  to  eighteen  different  entity  typea 
and  their  relationahipa.  It  can  produce  fifty-eight  unique 
reporta. 

7.  DUS  1100 

Marketed  by  Sperry  Computer  Syatema,  DMS  1100  ia  a 
CODASYL  DBMS  for  uae  with  all  Sperry  aeriea  1100  computera. 
Item  deacriptiona  are  baaed  on  COBOL-oriented  CODASYL 
apecif icationa  including  level  number,  name,  picture,  uaage, 
occurs,  and  occura  depending  on  clauaea.  Item  definitiona 
can  include  a  CHECK  clauae  for  data  validation. 

Data  baae  creation  and  input  are  accompliahed  via 
user  application  programs  or  with  a  special  "load"  schema. 
Modifications  require  some  reloading  and  recompilation  of 
programs.  The  Data  Dictionary  System  (DDS) ,  a  dependent. 


active  data  dictionary,  can  aid  data  base  revision  with 
impact  reports. 

Application  programming  can  interface  with  COBOL 
FORTRAN  and  PL/1.  DMS  1100  provides  two  other  data 
manipulation  languages.  QLP  1100  is  a  command-oriented  data 
manipulation  language  and  RPS  1100  is  a  form-oriented  screen 
image  report  language.  Both  languages  supplied  are  designed 
for  use  by  the  end  user. 

Automatic  and  utility  based  roll  back  and  recovery 
facilities  are  provided.  Roll  back  can  affect  only 
individual  users  or  programs,  or  all  active  programs  at  the 
time  of  system  failure.  Selective  file  recovery  is  possible 
and  an  entire  data  base  may  be  recovered  to  a 
pre-established  recovery  point. 

8.  DRS 

DRS  is  a  powerful  self-contained,  relational-1 i ke 
DBMS  produced  by  Advanced  Data  Management.  It  is  designed 
to  operate  with  most  DEC  VAX  and  PDP  systems,  as  well  as  IBM 
mainframes.  A  multi -processor  version  of  DRS  for  VAX  allows 
a  data  base  and  its  users  to  be  spread  across  several 
machines. 

There  are  two  types  of  files  supporting  the  physical 
structure  of  a  DRS  data  base.  The  first  is  the  Record 
Address  file  that  tracks  record  location  by  file  and  page. 
A  version  of  this  bit  map  marks  the  locations  of  qualifying 


records  after  a  retrieval  so  they  do  not  have  to  be  copied 
to  temporary  storage.  Secondly,  indexes  are  maintained 
through  inverted  files  in  a  B-tree  format.  Any  field  or 
combination  of  fields  can  be  indexed.  Even  partial  field 

indexing,  where  a  single  word  or  phrase  in  a  field  is 

> 

indexed,  is  available.  The  storage  area  for  records  can 
consist  of  up  to  1000  logically  concatenated  physical  disk 
files.  Each  file  is  divided  into  fixed  length  units  called 
pages.  The  structure  and  attributes  of  each  data  base  are 
stored  in  a  central  dictionary  data  base.  They  are  accessed 
via  an  interactive  display-oriented  utility  called  Data  Base 
Builder. 

Concurrent  read/write  access  to  a  data  base  is 
available  for  up  to  64  users.  Concurrent  read  only  access 
is  unlimited.  Automatic  locking  occurs  at  the  record  level 
while  a  record  instance  is  actually  undergoing  update. 

DPS  is  an  English-like,  self-contained  language  for 
query  and  update.  XBS  and  SIP  are  the  host-language 
interface  and  for ms-oriented  query  and  update  language 
respectively.  Link  modules  and  XBS  programs  may  be  written 
in  any  standard  compiled  language. 

9.  Encompass 

Tandem  Computers,  Inc.  have  developed  a 


self-contained  DBMS  for  use  on  all  Tandem  NonStop  systems. 
It  will  allow  data  and  applications  to  be  distributed  across 


•  255-nod«  network.  A  unique  relational  data  base  access 
method  named  ENSCRIBE  ensures  that  no  single  failure  will 
result  in  corruption  or  loss  of  data.  In  fact,  failed 
components  may  be  serviced  while  the  rest  of  the  system 
remains  in  operation.  The  Transaction  Monitoring  Facility 

M 

can,  if  a  failure  occurs,  back  out  an  entire  transaction 
across  all  nodes  of  a  distributed  system.  Data  bases  are 
reconstructed  by  rolling-forward  from  on-line  dumps  and 
audit  trails. 

The  data  dictionary  plays  an  important  role  for 
ENCOMPASS.  The  on-line  dictionary,  built  with  the  Data 
Definition  Language  Processor,  provides  a  view  of  relational 
data  bases.  Under  the  purview  of  the  dictionary,  these  data 
bases  can  be  queried  by  ENFORM,  the  query /report  writer 
language,  or  validated/updated  by  PATHWAY,  the  transaction 
processing  system.  ENFORM,  with  the  data  dictionary, 
supports  field  level  security  by  allowing  multiple 
dictionaries  to  describe  the  same  data  base.  Only  those 
fields  explicitly  mentioned  in  the  dictionary  are  accessible 
to  the  user  of  that  dictionary. 

10.  Express 

Management  Decision  Systems,  Inc.  claim  that 
EXPRESS,  their  relational  DBMS,  offers  the  widest  range  of 
decision  support  system  tools  using  a  single  command  syntax. 
These  tools  include  data  management,  reporting,  graphics. 
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mimulation,  ad  hoc  quary,  statistica,  and  modal ling. 
EXPRESS  ia  aval  labia  for  IBM  mainframa  and  Prima  400  or 


largar  computara.  A  larga  library  of  atatlatical,  plotting, 
financial,  and  market  modaling  routinaa  along  with  tha 
ability  to  aaaily  uaa  and  craata  naw  EXPRESS  commanda  makaa 
thia  DBMS  uaer  frianc^ly. 

Tha  data  baaa  ia  a  coll  act ion  of  mul tidimanaional 
variablaa.  Tha  uaar  may  work  with  up  to  256  dimanaiona  at 
one  time  and  may  eatabliah  hierarchical  relationahipa 
between  any  dimanaiona. 

Tha  ayatem  ia  daaignad  primarily  for  interactive 
proceaaing  although  batch  may  bo  accompliahed  by  atoring 
commanda  in  a  file.  Concurrent  read/write  acceaa  ia  not 
provided  by  tha  ayatem.  Read  only  acceaa  by  multiple  uaara 
ia  poarible. 

1 1 .  Focua 

Focua  and  PC  Focua  are  manufactured  and  aold  by 
Information  Buildara,  Inc.  They  are  daaignad  to  operate  on 
tha  IBM  370  and  IBM  PC  (minimum  of  SMB  external  atoraga) 
reapacti valy.  Aa  with  any  hierarchical  ayatem,  many-to-many 
relational-lika  atructurea  can  be  deaigned  but  preaent 
complicated  logical  viewa.  Focua  ia  the  Admini atrati ve  DBMS 
at  NPS.  More  information  can  be  found  in  Chaptera  4  and  5. 


12.  Intgl 'a  Database  In-formation  Sytarn  <IDI8) 


; 


IDIS  i*  «  standalone,  relational,  micro-systein 
package  with  mainframe  access  capability  to  SYSTEM  2000. 
Mainframe  data  download  statistics  are  provided  before 
actual  local  database  load  to  prevent  out  of  memory  errors. 

Intel  provides  spreadsheet  and  graphics  integration, 
a  word  processing  interface,  and  several  interactive  menu 
driven  utilities.  A  data  dictionary  is  integral  with  IDIS 
and  a  local  dictionary  driven  data  download  from  mainframe 
is  included. 

This  is  one  of  the  DBMSs  that  makes  full  use  of  the 
UNIX  (or  XENIX  by  Microsoft)  operating  system.  IDIS 
provides  access  to  XENIX  file  structure  and  word  processing 
interface  for  easy  cataloging  as  well  as  the  XENIX  mail  and 
calendar  facilities. 

13.  Integrated  Database  Management  System  (IDMS) 

IDMS  was  developed  by  Cullinet  Software  for  IBM 
360/370  series  computers.  A  dependent  data  dictionary 
called  Integrated  Data  Dictionary  is  also  available.  In 
combination,  these  two  constitute  a  powerful  CODASYL 
implementation  of  a  DBMS.  A  relational  version  called 
IDMS/R  is  also  available. 

Data  description  uses  standard  CODASYL  set 
relationships.  Data  manipulation  is  through  COBOL,  PL/1, 
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Assembler,  CALL,  or  FORTRAN.  An  option  Is  available  that 
allows  a  multitasking  environment  and  ensures  that  more  than 
one  task  does  not  update  the  same  record  at  the  same  time. 


Applications  programming  is  through  call  statements 
generated  by  a  preprocessor.  Operators  and  functions  are 
limited  to  those  provided  by  the  host  language. 

14.  IMS 

Up  to  31  on-line  application  programs  may  access  an 
on-line  data  base  using  IBM  Corporation's  DBMS  named  IMS. 
Since  IMS  is  designed  for  IBM  mainframe  computers,  a  heavy 
emphasis  is  placed  on  access  efficiency,  security,  and 
control . 

Special  storage  techniques  are  used  to  minimize 
storage  requirements.  Free  space  can  be  reserved  in  advance 
to  allow  later  insertion  of  segments  near  their  parents  or 
insertion  of  new  root  segments.  Deleted  segment  space  can 
be  reused  for  new  data. 

IMS  provides  automatic  logging  of  all  changes  to  any 
data  base.  It  also  contains  recovery  utilities  for 
restoration  without  re-eKecution  of  application  programs. 

Program  Isolation  Trace,  a  utility  provided  by  IMS, 
shows  locking  and  deadlocking  conditions.  IMPARS,  a 
productivity  aid,  can  be  used  to  report  internal  response 
time  and  resource  utilization. 


Dictionary  support  is 


available  through  DB/DC  Data  Dictionary  Systems,  an  IMS 
dependent  data  dictionary  package  also  by  IBM. 

IMS  is  best  suited  -for  real  world  data  applications 
which  exhibit  hierarchical  relationships. 

15.  In-f  o  i 

In-fo  is  a  mini -computer  oriented,  relational  data 
management  system  produced  by  Henco  Software  Inc.  An 
integrated  data  dictionary  is  used  to  describe  logical 
records  to  a  file  and  is  stored  separately  from  the  data 
base.  By  creating  a  dictionary  file,  INFO  can  access  files 
already  existing  in  the  system.  Minimum  input  validation  is 
also  accomplished  by  the  data  dictionary. 

A  combination  of  a  user-friendly  language  called 
INFO  and  multiple  add-on  products,  make  INFO  appealing  to 
end  users.  INFO-Veisagraph  provides  full  business  graphics 
linked  to  data  files.  INFO-Text  joins  unstructured  data 
created  by  a  word  processor  to  INFO  data  files.  Also,  a 
financial  planning  and  modeling  system,  called  MODEL,  can 
automatically  pull  data  from  INFO  to  the  correct  model  row 
and  column. 

The  programming  staff  is  assisted  by  INFO-Call  which 
links  INFO  to  programs  written  in  a  compiled  language. 
INFO-Flow  automatically  documents  INFO  application  programs. 


16.  Ingres 


A  DEC  mini  or  66000  based  micro  computer  with  -five 
megabytes  of  secondary  storage  is  all  that  is  required  to 
run  INGRES,  a  relational  DBMS  by  Relational  Technology,  Inc. 

As  with  most;  relational  systems,  relationships  are 
established  through  tables.  QUEL,  a  non-procedural  query 
language,  can  be  used  interactively  or  embedded  in  BASIC,  C, 
COBOL,  FORTRAN,  or  PASCAL. 

Query-By-Forms,  Report-By-Forms,  and  Qraph-By-Forms 
are  all  designed  to  free  the  user  from  systems  programming. 
Ad  hoc  queries,  reports,  and  graphics  can  be  obtained 
without  formal  programming.  Application-By-Forms  is  an 
integrated  application  development  system  used  to  accelerate 
the  programming  process. 

17.  Inquire 

A  modified  relational  structure  was  used  by  Infodata 
Systems  Inc.  to  design  INQUIRE  for  IBM  mainframe  computers. 
In  this  modified  structure,  each  record  entity  can  be  made 
up  of  a  flat,  single  entry  "owner"  element  with  repeating 
"member"  groups.  Similarity  between  this  modified 
relational  structure  and  the  hierarchical  model  is  useful  in 
that  hierarchical  structures  are  a  byproduct  of  this 
approach.  It  could  just  as  easily  have  been  called  a 
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modi-fisd  hierarchical  structure  with  network  relationships 


as  a  byproduct. 

A  single  command  language  for  query,  report,  and 
data  maintenance  provides  system  continuity.  Custom  macros 

can  be  used  to  create  additional  commands. 

; 

18.  The  Knowledge  Manager  (Knowledgeman) 

Micro  Data  Base  Systems,  Inc.  developed 
KNOMLEDGEMAN,  a  relational  DBMS,  for  use  on  the  IBM  PC. 

KNOMLEDGEMAN  structured  programming  language  can  be 
used  to  invoke  all  data  management  commands.  It  supports 
thirty  built-in  functions  as  well  as  if-then-else,  do-while, 
and  case  logic.  In  addition,  it  is  capable  of  output 
conversion  to  ASCII,  BASIC,  or  DIF  format. 

During  data  base  creation,  the  user  is  prompted  for 
values  via  a  standard  or  customized  CRT  form.  At  that  time, 
multiple  indexes  can  be  defined  for  each  relation.  Index 
keys  can  be  made  up  of  multiple  fields  or  expressions 
involving  multiple  fields.  KNOWLEDGEMAN  allows  virtual 
fields  which  require  no  storage  space,  as  they  only  exist 
during  execution.  Virtual  fields  may  also  be  defined  by 
expressions  involving  other  fields. 

A  limited  distributed  capability  is  provided  by  a 
facility  for  downloading  MDBS  III  DBMS  data  files  into 
KNOWLEDGEMAN  for  local  use. 


19.  The  Micro  Data  Base  System  III  (MDBS  III) 


Post-relational  is  how  ISE-USA,  the  creator  of  MDBS 
III,  classifies  their  DBMS.  MDBS  III  supports  hierarchical, 
relational,  and  CODASYL  views  as  subsets  of  its 
capabilities.  Qn^-to-one,  one-to-many,  many-to-many , 
recursive  one-to-many,  recursive  many-to-many,  and  various 
other  relationships  are  directly  represented  by  name  in 
MDBS  III.  This  allows  a  relational  Join  to  be  accomplished 
by  simply  specifying  relationship  names.  Also,  virtual 
views  are  supported  that  lack  the  access  and  storage 
inefficiencies  of  actual  tables. 

MDBS  III  provides  a  query  language  that  is 
comparable  to  SQL  (by  IBM)  and  an  interactive  data 
manipulation  language  that  can  be  embedded  in  over  twenty 
host  languages.  A  data  dictionary  is  integral  with  the 
system  and  can  be  accessed  through  the  query  or  data 
manipulation  language. 

In  addition,  MDBS  III  provides  several  end  user 
oriented  applications.  Screen  Master  is  an  I/O  management 
system.  The  Report  Definition  Language  (RDL)  along  with  the 
RDL  Analyzer  allow  a  non-programmer  to  specify  the  format  of 
a  desired  report.  RDL  can  also  automatically  generate  C 
source  code  for  the  requested  report. 
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20.  Nomad2 


Nomad2,  a  relational  DBMS  by  D&B  Computer  Services ^ 
is  designed  -for  on-line  (IBM  main-frame)  interactive  problem 
solving  by  end  users.  It  employs  an  English-like 
non-procedural  commar^d  language  -for  reporting  and  updating. 
Relational  and  multipath  hierarchical  data  base  structures 
are  also  supported. 

The  data  management  -facility  allows  for  easy 
creation  and  maintenance  of  data  base  files.  Data 
validation  spans  the  range  from  discreet  values  and  sets  to 
complex  logic  that  may  be  made  a  part  of  the  data  base 
description.  The  SLIST  facility  provides  integrated  data 
dictionary  functions  such  as  access  to  names  and 
characteristics  of  data  items. 

The  schema  may  be  modified  or  reorganized  without 
dumping  and  reloading  data.  System  checks  ensure  that  no 
changes  are  made  until  their  validity  is  verified. 
Hierarchical  segments  may  also  be  added,  provided  they  do 
not  interrupt  an  existing  path. 

Nomad2  is  designed  as  a  shared  data  base  facility 
which  directly  supports  multiple  concurrent  write  access. 
Conflicting  updates  are  handled  automatically  and  deadlock 
situations  are  prevented  by  the  system. 
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Numerous  other  aids  such  as  an  automatic  procedure 
generator  and  an  interactive  debugging  routine  make  N0hAD2  a 
stand-alone  applications  development  tool. 

21 .  Oracle 

Oracle  was  ^one  of  the  first  relational  mainframe 
packages  to  be  commercially  available  on  a  micro  computer. 
It  is  highly  portable  and  flexible  enough  to  support  ad  hoc 
queries  as  well  as  serious  application  programming. 

Oracle  Corporation  implemented  SQL  Plus,  an  extended 
version  of  IBM's  SQL/DS,  as  the  standard  interface  to 
ORACLE.  SQL  serves  as  a  query,  data  manipulation,  and  data 
definition  language  and  provides  full  dictionary  support. 
Host  language  precompilers  are  available  for  most  languages 
with  embedded  call  statements. 

Normalized,  two-dimensional  tables  are  used  to 
represent  all  data.  Access  methods  are  determined 
dynamically  by  available  inverted  keys,  physical  sequences, 
uniqueness  characteristics,  and  data  distribution. 

22.  Ramis  II 

Mathematics  Products  Group  markets  Ramis  1 1  as  the 
first  fifth  generation  software  product  for  use  on  IBM 
mainframe  and  compatible  hardware.  Hierarchical,  network, 
and  relational  file  structures  are  supported.  The  natural 
language  processor,  Ramis  II  English,  is  based  on  the 


principles  of  artificial  intelligence  and  can  understand  and 
answer  queries  made  in  everyday  English. 

Reporter,  a  non-procedural  language,  is  used  to 
produce  tabular  reports.  Application  programming  can  be 
done  in  COBOL,  PL/1,  Assembler,  and  FORTRAN  through  calls  to 
the  data  manager. 

Failure  protection  is  provided  by  transaction  log 
files.  Access  security  and  control  are  accomplished  through 
passwords  and  encryption  at  all  levels  from  data  base  to 
individual  fields. 

A  number  of  special  utilities  are  also  provided  that 
make  Ramis  II  a  portable  and  complete  application 
development  environment.  REF  extends  access  to  non-Ramis 
files  such  as  Adabas,  DL/1,  IDNS,  IMS,  and  Total.  RAMASTER 
is  a  file  dictionary  that  contains  information  about  each 
field.  F8M  allows  user-defined  screen  formats  of  up  to  99 
frames  to  be  created.  RAMLink  provides  a  PC-to-mainf rame - 
link. 


23.  Structured  Query  Language  /  Data  System  (3QL/D8) 

SQL/OS,  by  IBM,  is  setting  the  standard  in  industry 
for  a  relational  DBMS.  It  is  designed  for  use  on  IBM  System 
370  computers. 

SQL,  the  system  language,  can  be  embedded  in  COBOL, 
FORTRAN,  PL/1,  Assembler,  or  used  solely  in  an  interactive 
mode.  It  is  the  most  imitated  aspect  of  SQL/DS.  Most  other 
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systvm  functions  such  ss  data  bass  craation, 


failurs 


protsction,  and  input  validation  provids  adequata 
capabilitias  but  ara  of tan  ovarshadowad  by  mors  racant  DBMS 
devalopmants. 

24.  System  2000  ^ 

IBM,  UNIV/AC,  CDC,  and  CYBER  computars  ara  all 
compatibla  with  Systsm  2000,  a  DBMS  producad  by  Intal 
Systams  Corporation. 

System  2000  supports  linear,  hierarchical,  network, 
and  relational  logical  structures.  Each  data  base  is 
composed  of  up  to  six  direct  access  tables  such  as  the 
integrated  data  dictionary,  indexes,  and  raw  data.  Initial 
data  base  loading  may  be  accomplished  one  at  a  time  or  via 
PLEX  (Programming  Language  Extension),  a  high  spaed  load 
utility  . 

The  Integrated  Data  Dictionary  plays  an  important 
role  in  System  2000.  For  each  physical  data  base,  the 
dictionary  parameters  include  archives,  update  Journals,  and 
before-image  logs.  All  internal  restructuring  is  done 
automatically  by  the  Basic  Data  Dictionary  Language.  It 
also  provides  password  based  security  down  to  the  individual 
item  level.  Input  data  can  be  validated  for  size,  type,  and 
picture  specified  by  the  schema  definition.  Additionally, 
report  requests  may  be  made  from  catalogued  procedures 
stored  within  the  Basic  Data  Dictionary. 


System  2000  offers  several,  powerful,  user-oriented 
interfaces.  Quest  is  a  free-form  query  and  update  language. 
Genius  is  a  conversational  report  writer  and  syntax 
generator.  QUEX  (Query/Update  by  Example)  is  a  menu  driven 
formatted  screen  query  and  update  system.  Lastly,  System 
2000  On  Line  Operations  (SOLO)  offers  menu  driven  access  to 
all  previously  mentioned  interfaces  plus  Report  Writer, 
Tell-A-Graf  (graphics  package),  and  the  Data  Definition 
Language. 

25.  Total 

In  a  survey  conducted  by  Cincom  Systems,  Inc.,  Total 
was  shown  to  be  Integrated  into  an  average  of  41%  of  all 
user  applications.  This  makes  Total  the  most  widely  used 
DBMS  by  a  margin  of  almost  two-to-one  over  the  next  leading 
system.  Total  operates  on  28  different  computers  on  40 
separate  operating  ayatems.  It  is  designed  to  accommodate 
future  hardware  changes  and  promote  distributed  processing. 

Data  base  creation  can  be  done  via  user  application 
programs  or  optional  data  base  administrator  utilities. 
Access  methods  are  dependent  on  hardware.  Adding  new 
elements  or  paths  requires  data  base  regeneration  but  not 
necessarily  program  modification.  Application  programming 
can  be  done  using  COBOL,  PL/ I,  or  FORTRAN. 

Two  recovery  types,  point-of-f ai lure  and  full 
system,  can  be  accomplished  by  applying  before  images  in 


DBA 


revarss  order  to  the  latest  checkpoint.  Full 

capabilities  to  control  user  access  includes  subschema  which 
specifies  user  password,  usable  data  item  names,  and  -file 
access.  Deadlock  is  controlled  by  a  DBA  specified  time-out. 


SB 


IV.  THE  DATA  DICTIONARY 


A.  CONCEPT 

; 

By  nature,  database  processing  involves  the  sharing  of 
resources.  A  DBMS  has  the  advantages  of  space  savings, 
increased  processing  speed,  and  enhanced  data  integrity  as  a 
result  of  this  sharing.  Nevertheless,  as  a  database  grows, 
many  of  the  advantages  can  be  negated  by  poor  programming 
discipline  and  data  standards.  If  programmers  continue  to 
code  unnecessary  new  procedures  with  unique  element  names 
for  each  new  application,  the  database  can  suffer  from  data 
redundancy.  This  can  cause  a  system  to  become  more 
difficult  and  expensive  to  maintain.  This  shared  data  must 
be  protected  through  standardization  to  ensure  data 
integrity  and  maximize  management  control.  At  NPS,  the  only 
standards  are  those  imposed  by  the  programmers  themselves. 
A  standard  name,  format,  and  relationship  for  every  entry  in 
the  data  base  must  be  established.  This  is  the  basic 
premise  behind  a  data  dictionary.  It  is  simply  a  way  to 
accumulate,  update,  and  report  information  about  data.  As  a 
minimum,  the  data  dictionary  should  give  the  names,  type, 
length  and  description  of  all  data  items  in  use.  Users 
should  be  restricted  to  only  those  representations  in  the 
dictionary.  If  a  piece  of  data  is  defined  in  more  than  one 


«re«,  a  need  tor  multiple  processes  to  update  this  data 
arises. 

Initial  implementation  of  a  data  dictionary  may  require 
eKtensive  data  modification.  Many  large  data  base  systems 

have  several  thousand  unique  data  items.  The 
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inter — departmental  coordination  required  to  standardize, 
define  and  name  these  data  items  is  difficult  at  best.  The 
Data  Base  Administrator  (DBA)  is  responsible  for  setting 
standards  and  often  encounters  resistance  from  programmers 
and  users.  The  longer  NFS  delays  in  appointing  a  formal  DBA 
with  authority  to  establish  and  maintain  standards,  the 
harder  the  process  will  become.  In  the  initial  stages  of 
standardization,  the  programmers  and  users  can  feel  limited 
or  hindered  in  their  normal  routine.  They  must  learn  a  new 
set  of  rules  and  comply  with  them.  In  their  minds,  these 
new  standards  are  Just  something  to  make  the  DBA's  Job 
easier  at  the  expense  of  their  own.  Sometimes,  their 
feelings  are  somewhat  Justified.  If  the  data  dictionary  is 
simply  used  to  store  information  about  data  without 
rigorously  enforced  data  administration  standards,  the  only 
advantage  will  be  the  ability  to  produce  reports  that 
document  redundant  processes  and  data. 

The  goal  of  a  data  dictionary  is  not  merely  to  document 
all  the  data  items  contained  in  a  database,  but  to  allow 
access  to  all  corporate  knowledge.  A  data  dictionary  can 
span  programs  and  databases.  It  may  include  entity  types 


-from  fields  and  formats  to  memos  and  relevant  publications. 
It  provides  programmers  and  users  with  a  bridge  to 
facilitate  communication  during  application  program 
development.  By  simplifying  the  development  process,  the 

user  can  become  more  involved  in  system  design,  thereby 
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reducing  the  demand  on  programmers  and  programming  backlog 
at  NPS.  CRef.  7ipp.  89-953 

A  data  dictionary  is  in  fact  a  data  base  about  data 
bases.  Consequently,  it  must  either  be  dependent  on  a  DBMS 
or  contain  many  of  the  same  components.  Among  the  most 
important  components  of  a  DBMS  as  well  as  a  data  dictionary 
are  the  languages  necessary  for  query,  data  manipulation, 
and  data  definition. 


*  Data  Definition  Language  <DDL>.  Language  for  defining 
type,  format  and  length  of  data  dictionary  entries. 
Data  entry  validation  may  be  based  on  definition. 

*  Data  Manipulation  Language  (DML) .  English-oriented, 
on-line  or  batch  language  for  inserting,  changing  and 
deleting  entries  and  relationships.  Also  used  for 
accessing  and  obtaining  reports  of  entities  and  related 
entities.  A  set  of  macroinstructions  or  call  statements 
provided  by  a  particular  DD/DBMS. 

*  Query  Language  (QL) .  User  oriented  DML  directed  mainly 
at  interactive  ad  hoc  requests. 

*  Utilities.  Commands  for  loading,  recovery,  source 
language  code  generation,  interfacing  to  other  software 
products,  scanning  source  code  for  data  dictionary 
entries,  etc. 

*  Report  Writer.  Formatting  commands  for  high  volume 
printed  reports  of  entries  and  related  entries. 

*  Host  language  Interface.  Allows  the  programmer  to 
access  DBMS  files  through  calls  in  a  host  language. 


*  Communication.  Link  bmtw««n  micro  and  mainframa  for  tha 
purposa  of  sharing  data. 

Whila  thasa  high  laval  languagas  const ituta  tha  data 
dictionary  systam,  information  about  data  cal lad  matadata  is 

what  makes  up  the  data  dictionary  data  base.  Soma  of  tha 
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possible  attributes  of  entries  in  a  data  dictionary  data 
base  are  listed  below. 

*  Attribute  name  and  synonyms 

*  Authorization  password <s)  for  retrieval,  update,  delete, 
etc. 

*  Data  type  and  format 

*  Range  of  values  that  may  be  stored 

*  Units  in  which  the  entity  is  represented,  e.g.,  feet, 
meters 

a  Name  of  other  entities  that  may  initialize,  update,  or 
delete  the  data  value 

*  Programming  language <s)  for  which  it  is  written 

*  Status,  i.e.  if  the  entity  is  in  development,  testing, 
damaged  or  production  status 

*  Text  (any  text  or  comments  may  be  written) 

Layered  above  the  dependent  or  independent 
implementation  of  a  data  dictionary  is  its  functional 
ability  to  interact  with  a  DBMS.  A  data  dictionary  is 
considered  active  if  programs  and  processes  depend  on  it  for 
their  metadata.  A  passive  data  dictionary  is  usually 
embedded  within  another  system  and  therefore  dependent  on 
that  system.  An  active  data  dictionary  can  be  embedded 


within  another  system  or  completely  independent  with 
interfaces  to  many  different  systems.  Its  primary  functions 
include  identifying,  locating,  controlling,  reporting,  and 
manipulating  metadata.  With  a  completely  active  dictionary, 

users  interface  with  the  DBMS  only  through  the  dictionary. 

>  , 

The  scope  of  the  activity  varies,  and  a  fully  active  data 
dictionary  does  not  yet  exist. 

B.  COMMERCIAL  DATA  DICTIONARY  SYSTEMS 

Data  dictionary  systems  have  evolved  recently  and  become 
an  increasingly  useful  tool  for  Data  Base  Administrators, 
auditors,  systems  analysts,  programmers  and  users.  In  many 
organizations  where  data  bases  and  information  systems 
achieve  a  high  degree  of  evolution  and  sophistication,  the 
data  dictionary  becomes  a  practical  necessity.  NPS  has  a 
large  number  of  potential  data  intensive  applications  well 
suited  for  a  data  base  environment.  It  is  plausible  to 
assume  that  NPS  could  become  increasingly  dependent  on  a 
data  base  and  information  system.  The  data  dictionary  is  a 
specialized  data  base  management  system,  or  application  of 
an  existing  DBMS.  The  data  base  is  a  repository  of 

descriptive  information  about  the  data  bases,  programs  and 
other  entities  associated  with  information  systems  practice. 
There  are  two  types  of  data  dictionary  systems,  dependent 
and  independent.  An  independent  DD  is  self-contained  and 
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has  its  own  reporting  and  maintenance  programs.  A  dependent 
data  dictionary  is  usually  implemented  as  an  application  o-f 
a  DBMS  and  is  dependent  on  that  particular  DBMS  to  function. 


1  .  Independent 


DBMS  vendors  are  now  marketing  data  dictionaries 
with  growing  capabilities  for  use  specifically  within  their 
DBMS  environments.  However,  some  vendors  who  do  not  market 
a  DBMS  have  developed  data  dictionaries  to  be  nearly 
sel f -standi ng ,  that  is,  they  do  not  require  the  use  of  a 
DBMS.  At  the  same  time,  such  products  have  interfaces  to 
generate  data  descriptions  specific  to  many  popular  DBMSs. 
The  price  range  varies  from  about  *15,000  to  *40,000 
depending  on  the  particular  vendor,  version  of  the  system 
and  options  included.  Table  3.1  summarizes  the  interface 
capabilities  of  several  of  the  major  data  dictionary 
systems.  Data  Catalog  2  and  Datamanager  are  the  only  two 
listed  that  can  be  considered  free-standing  or  independent. 
The  choice  is  arbitrary  and  should  not  be  interpreted  as 
indicative  of  the  author's  preferences  nor  overall  product 
ratings.  Information  provided  in  Table  VIII  was  derived 
from  CRef.  SJ. 


2.  DBMS  Dependent 


A  dependent  data  dictionary  is  more  often  than  not  a 
commercially  available  package,  designed  for  a  specific 
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TABLE  VIII 


COMMERCIAL  DATA  DICTIONARIES 


SUPPLIER 

NAME 

DBMS  REQ.  1 

DBMS  USED  1 

CULL I NET 

IDD 

(INTEGRATED 
DATA  DICT¬ 
IONARY) 

1 

IDMS  1 

1 

1 

1 

IDMS 

IBM  CORP. 

DB/DC  DATA 
DICTIONARY 
SYSTEMS 

1 

1 

IMS  or  DL/1  1 

1 

1 

IMS 

MANAGEMENT 
SYSTEMS  AND 
PROGRAMMING 
LTD. 

DATAMANAGER 

1 

NONE  1 

1 

1 

1 

1 

IDMS 

TOTAL 

IMS 

ADABAS 
SYSTEM  2000 

TSI 

INTERNATIONAL 

DATA  CATALOG  2 

1 

NONE  1 

1 

1 

1 

1 

IMS 

TOTAL 

ADABAS 

DMS-1100 

DATA  MANAGER 

UN I VAC 

DATA  DICT¬ 
IONARY  (DDS) 

1 

1 

DMS-1100  1 

1 

DMS-1100 

1 

f 

DBMS.  The  FOCUS  Data  Dictionary  <FOCUSDD)  is  itself  a  FOCUS 
data  base  and  is  considered  DBMS  dependent.  To  an 
organization  that  only  uses  one  DBMS,  a  dependent  data 
dictionary  can  be  an  advantage.  For  example,  FOCUSDD  can 
use  all  FOCUS  capabilities  directly  to  analyze  its  contents 
and  perform  ad  hoc  analysis.  Users  need  only  learn  one 
system  versus  two  with  an  independent  data  dictionary. 


The  FOCUS  Data  Dictionary  (F0CU8DD)  la  a 
comprahansi v«  data-  managamant  tool  that  can  monitor, 
control,  and  audit  appl icationa.  It  aervaa  aa  a  central 
repoaitory  for  the  information  on  all  el  amenta  of  FOCUS 

ayatema.  The  following  highlighta  were  summarized  from 

; 

CRef.  9ipp.  1-7D. 


«  Menu-driven  operationi 

FOCUSDD  ia  an  online,  menu  driven  ayatem.  It  ia 
built  around  a  MAIN  MENU  liating  four  baaic  optional 
Information  Proceaaing,  Basic  Reporting,  System 
Maintenance,  and  entrance  into  FOCUS  for  ad  hoc 
analysis.  The  first  three  options  on  the  MAIN  MENU  lead 
to  a  sub-menu,  which  in  turn  breaks  out  into  detailed 
menus  providing  a  full  range  of  options. 

s  Analysis  of  Master  File  and  FOCEXEC  informationi 

The  FOCUS  Data  Dictionary  analyzes  FOCUS  Master 
Files,  FOCEXECs,  COBOL  programs,  and  CMS  EXECs.  It 
records  information  for  fields,  files,  input/output  data 
sets  and  program  CALLS  used.  After  analyzing  a  Master 
File,  it  posts  information  regarding  Masters,  segments, 
cross-referenced  segments  and  data  fields  into  the 
dictionary.  For  FOCEXECs  and  other  supported 

procedures,  it  generates  cross-referenced  reports 
listing  referenced  fields,  system  commands,  and 
input/output  data  sets  used.  Analysis  can  be  done  on  an 
individual  file  or  group  of  files. 

*  Resource  accounting  facilitiesi 

This  feature  captures  and  maintains  system  resource 
utilization  statistics  for  FOCEXECs  by  program.  As  a 
FOCEXEC  is  executed,  the  following  information  is 
collected  and  produced i 

-  Date  of  last  execution 

-  Total  number  of  executions 

-  USERID  of  last  execution 


TOTAL  CPU  seconds 


-  VIRTUAL  CPU  «»cond» 

-  Total  STARTIO  commands 

-  Total  CLOCK  TIME 

*  Automatic  dictionary  update  featurei 

An  automatic  Dictionary  Update  feature  provides 
facilities  for  automatically  posting  all  supported  file 
types  into  the  dictionary.  Updating  is  based  on 
mnemonic  values  stored  in  the  data  base  under  a  standard 
naming  convention  provided  by  FOCUSDD.  All  files 
containing  these  values  will  automatically  be  posted, 
analyzed,  and  updated. 

The  user  is  prompted  to  determine  whether 
information  about  Masters,  FOCEXECs  and  other  programs 
no  longer  in  existence  should  be  deleted  or  maintained. 

Menu-driven  procedures  for  full-screen  system 
maintenance  include! 

-  Program  description  query/update 

-  Field  description  update 

-  Program  deletion 

-  Master  File  description  update 

-  Master  File  deletion 

*  Program  change  log  facilities! 

Provides  a  built-in  audit  trail  of  program  and 
system  modifications.  The  user  can  create,  query, 
update  or  delete  entries  to  the  Log.  This  allows  easy 
documentation  and  monitoring  of  all  changes. 

*  Automatic  generation  of  program  documentation! 

For  each  program  in  the  dictionary,  a  formatted 
report  is  generated  which  displays  program  narrative  and 
an  input/output  list  including  data  bases  accessed, 
external  routines,  and  the  actual  source  listing. 

*  Comprehensive  set  of  standard  reports! 

A  built-in  series  of  sixteen  standard  reports 
display  all  available  information  on  programs,  data  and 


their  relationships.  Report  selection  is  ntenu-driven, 
featuring  terminal  or  printed  report  generation.  Key 
reports  includei 

-  Catalogues  of  Master  Files/Programs 

-  FOCEXEC  listing  by  filename 

-  Keyword  string  query  by  FOCEXEC 

-  Program  calls/called  by  program 

-  Fieldname  string  query  by  filename 

-  Field  listing  by  FOCEXEC 

-  Resource  analysis  by  USERID  and  program 

FOCUSDD  is  completely  menu-driven.  It  provides 
facilities  for  information  storage,  analysis,  reporting, 
documentation  and  auditing.  It  can  perform  Software  Nesting 
Analysis,  resolve  calling  sequences  up  to  ten  levels  deep, 
and  provide  a  complete  "calls/called  by"  analysis  for  user 
specified  programs. 

The  DBA  is  provided  a  powerful  means  of  controlling 
applications  with  FOCUSDD's  Automatic  Dictionary  Update 
facility.  Using  standard  naming  conventions,  this  feature 
automatically  posts  all  supported  file  types  in  the 
dictionary. 

C.  BENEFITS 

The  major  benefits  of  a  data  dictionary  derive  from  its 
flexibility  to  accommodate  changes  and  its  centralized 
location.  To  successfully  implement  any  DDS,  a  commitment 


to  the  design,  implementation,  and  proper  usage  is  necessary 


from  all  levels  of  management.  Programmers  must  restrict 
their  work  area  and  ensure  that  only  valid  and  authorized 
changes  are  made  to  the  system.  Lastly,  it  is  essential 

that  a  DBA  be  assigned  to  ensure  compliance  with  the  rules 
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of  the  system.  CRef.  lOspp.  38-44D 

Both  types  of  data  dictionaries  have  relative 
advantages.  An  independent  DD  can  ensure  consistency  of 
data  definitions  by  verifying  and  editing  all  data  entries 
before  storage.  A  dependent  dictionary  can  be  integrated 
into  an  existing  DBMS  environment  with  minimum  user 
disruption.  Also,  a  dependent  dictionary  can  be  useful  in 
the  case  where  all  data  is  stored  under  a  single  DBMS. 

There  is  no  question  that  the  stand-alone  DD  is 
potentially  more  powerful  than  the  dependent.  In  some 
situations,  such  as  multiple  DBMSs,  it  may  be  the  only  way 
to  maintain  centralized  control  of  data.  Considering  cost 
and  performance,  the  conclusion  to  be  drawn  is  that  the 
dependent  dictionary  is  more  appropriate  for  organizations 
with  existing  data  organized  around  a  single  DBMS.  The 
independent  dictionary  is  best  suited  for  system  start-up 
and  multiple  DBMS  organizations. 


V.  ANALYSIS  AND  GENERAL  DESIBN 


A.  FOCUS  DESIGN  CONSIDERATIONS 

f 

At  the  Naval  Postgraduate  School ,  FOCUS  DBMS  is  used 
as  the  administrative  data  base  facility.  The  Office  of  the 
Director  of  Admissions  employs  two  programmer /analysts  to 
develop  application  programs  and  maintain  data  integrity. 
Due  to  the  large  Investment  in  time  and  money  associated 
with  FOCUS,  the  Director  of  Admissions  was  predisposed  to 
its  use  for  new  applications.  A  formal  requirements 
analysis  was  not  conducted,  but  a  recommendation  to  purchase 
PC  FOCUS  was  made.  When  used  on  compatible  micro-computer 
hardware,  PC  FOCUS  would  reduce  the  amount  of  mainframe  CPU 
time  required.  Data  could  be  downloaded  to  a  personal 
computer  in  the  Director  of  Admissions  office  for 
manipulation  and  reporting.  Additionally,  application 
programs  could  be  generated  on  the  PC  and  executed  on  the 
mainframe  at  times  other  than  peak  load. 

FOCUS  is  based  on  the  hierarchical  model  in  which  a 
parent  segment  may  have  one  or  many  descendant  segments. 
The  child  is  limited  to  a  single  parent.  This  one-to-many 
relationship  is  denoted  in  diagrams  by  either  projected 


boxes  or  a  double  headed  arrow  connecting  parent  to  child. 
Solid  lines  are  used  to  infer  structural  relationships  and 


dottsd  lines  for  cross-reference  or  index  to  identical 
fields  in  other  segments. 

The  discussion  that  follows  is  based  on  information 
contained  in  CRef.  113. 


1.  Data  Description  Language 


The  description  of  a  FOCUS  file  is  typed  into  a  CMS 
file  whose  filetype  is  MASTER.  The  CMS  filename  becomes  the 
name  by  which  the  file  is  known  to  FOCUS.  For  example,  the 
FOCUS  file  "STUDENTS"  must  have  a  file  description  stored 


with  a  CMS  filename  of  "STUDENTS  MASTER".  Three  cl< 


attributes  are  used  to  describe  a  FOCUS  file.  They  are  file 
attributes,  segment  attributes,  and  field  attributes. 
Figure  S. 1  below  gives  an  example  of  a  single  segment  master 
description. 


FILE  DECLARATION  I  FILENAME- 


SEO  DECLARATION  I SEGNAME- 


,SUFFIX- 


,SEGTYPE-  , PARENT- 


DATA  OR 
FIELD 

DECLARATIONS 


IFIELDNAME- 
IFIELDNAME- 
IFIELDNAME- 
IFIELDNAME- 


,ALIAS- 
,ALIAS> 
,ALIAS- 
.ALIAS- 


, FORMAT- 
, FORMAT- 
, FORMAT- 
.  FORMAT- 


Figure  5.1  Sample  Focus  Master  Description 


Attributas  d*Bcrlbing  ths  -flla,  segmantB,  and  -fialda 
o-f  a  FOCUS  fil*  ara  typad  in  fraa  form  comma  dalimitad 
format.  A  dollar  sign  (^)  signifias  the  end  of  the 
description  of  each  element  and  a  checking  procedure  can  be 
used  to  locate  typing  errors  and  rule  violations  before  to 
data  entry.  After  data  entry,  it  is  no  longer  possible  to 
make  arbitrary  changes  to  the  file  description.  Any  change 
to  the  master  file  that  necessitates  a  change  to  the 
physical  data  base  requires  reorganization  of  the  data. 
This  does  not  imply  weak  logical /physical  independence. 
Data  must  be  reconstructed  into  a  form  that  coincides  with 
the  master  description.  It  would  be  nice  if  FOCUS  would 
reindex  files  automatically.  Nevertheless,  the  REBUILD 
utility  provides  options  for  rebuilding  a  FOCUS  file, 
reorganizing  a  FOCUS  file,  and  for  indexing  fields  in  a 
FOCUS  file  after  data  entry. 

Both  static  and  dynamic  cross-referencing  of  files 
are  available  with  advantages  and  disadvantages  to  each. 
Static  cross  references  are  specified  in  the  master 
description  and  are  therefore  always  active,  but  require  the 
use  of  the  REBUILD  utility  to  change.  Dynamic 
cross-reference  is  accomplished  through  the  JOIN  command. 
It  does  not  taka  up  file  space  by  being  pre-posi ti oned  in 
the  master  description  and  can  be  easily  invoked  when  needed 
to  link  an  entire  file  structure.  On  the  negative  side,  the 
JOIN  command  must  be  issued  during  each  session,  can  only 
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link  entirs  file  structures*  and  is  slower  after  first  usage 
than  a  static  cross  reference. 

Prior  to  use  of  static  or  dynamic  cross-referencing, 
at  least  one  field  in  the  desired  segment  of  each  file  must 

be  of  type  "I"  or  indexed.  This  is  accomplished  through 

> 

field  attributes  in  the  MASTER  file.  Any  number  of  fields 
may  be  indexed  on  a  segment,  although  only  those  which  have 
common  values  in  other  files  are  practical  candidates.  The 
presence  of  the  index  is  crucial  for  the  operation  of  the 
cross  reference  facilities.  Any  number  of  external  sources 
may  locate  and  thereby  share  a  segment  because  of  it. 

2.  Data  Manipulation  Language 

Once  a  MASTER  file  has  been  constructed  and  found 
free  of  errors,  data  can  be  entered  into  a  FOCUS  data  base 
file.  A  non-procedural,  fourth  generation  data  manipulation 
language  is  used  for  all  phases  of  data  entry,  manipulation, 
and  reporting.  The  language  is  divided  into  two  functional 
areas  called  the  Transaction  Processor  and  the  Dialogue 
Manager.  The  purpose  of  the  transaction  processor  language 
is  to  facilitate  modification  of  information  in  a  FOCUS  data 
base  without  having  to  write  a  computer  program.  The 
transaction  processor  is  entered  by  typing  the  FOCUS  command 
MODIFY  followed  by  the  name  of  the  file  to  be  changed. 

The  transaction  processor  has  the  ability  to  accept 


input  in  several  forms 


FIXFORM  specifies  fixed  format  data 


with  aach  field  appearing  in  a  set  position  of  the  record. 
When  FIXFORM  is  used  the  name  of  the  data  fields  and  the 
number  of  characters  to  be  processed  must  be  specified. 
Under  normal  usage  FIXFORM  does  not  specify  the  source  of 

the  data  input  transactions.  Instead,  the  subcommand,  DATA 

> 

ON,  is  usually  placed  at  the  end  of  the  procedure.  The 
PROMPT  subcommand  specifies  that  the  user  will  enter  data 
interactively  in  response  to  prompts  from  FOCUS.  When 
PROMPT  is  used,  FOCUS  will  request  that  the  operator  type 
the  data  values  in  response  to  prompting  messages.  Only  one 
field  at  a  time  is  requested,  but  the  operator  has  the 
option  of  using  free  form  comma  delimited  format  to  input 
several  values  at  a  time.  FOCUS  will  then  skip  ahead  and 
resume  prompting  for  any  values  not  yet  entered. 
Preformatted  CRT  screens  for  f i 1 1-in-the-blank  data  entry 
can  be  designed  using  the  CRTFORM  subcommand.  The  FREEFORM 
subcommand  can  be  used  to  alter  the  natural  order  of  data 
input  from  that  described  in  the  MASTER  file. 

The  basic  operation  during  transaction  processing  is 
to  match  values  from  a  transaction  to  corresponding  values 
in  a  data  base  and  take  action  depending  on  the  status  of 
the  match.  The  MATCH  subcommand  is  used  to  designate  fields 
to  match.  All  key  fields  in  each  segment  must  be  specified. 
Fieldnames  can  always  be  referenced  by  either  their  full 
fieldname,  alias,  or  shortest  unique  truncation.  The 
actions  to  be  taken  following  the  MATCH  subcommand  are 


speci-fied  through  th«  ON  MATCH  and  ON  NOMATCH  subcommand*. 
A  short  dsscrlption  o-f  sach  of  the  possible  actions  is  given 
bel ow. 


REJECT 

UPDATE 

DELETE 

COMPUTE 

INCLUDE 

VALIDATE 

TYPE 

PROMPT 

FREEFORM 

CRTFORM 

FIXFORM 

CONTINUE 


The  transaction  is  considered  a 
dupl icate. 

>  , 

If  a  match  is  found,  the  fields 
specified  will  be  updated. 

The  matched  record  segment,  all 
dependent  records,  references,  and 
indexes  are  deleted. 

The  expressions  that  follow  may  refer  to 
transaction  values  or  data  base  values 

before  or  at  the  point  of  match.  These 
new  values  may  be  used  to  update  the 
data  base. 

A  data  base  record  is  to  be  included. 
This  is  the  basic  input  process. 

The  expressions  may  refer  to  the  same 
values  as  COMPUTE.  If  the  logic  of  the 
expression  evaluates  to  false,  the 

transaction  is  rejected. 

A  message  may  be  typed  in  response  to 
MATCH  or  NOMATCH  logic. 

Prompts  user  for  specified  fields. 

Additional  data  is  read  from  a 

transaction  file. 

Beginning  or  continuation  of 

f i 1 1-in-the-blank  CRT  screen. 

Same  as  FREEFORM 

This  is  the  default  option  when  a 
further  MATCH  subcommand  in  present,  but 
it  is  recommended  that  action  be  defined 
explicitly. 


60T0 


Unconditional  branch  to  named  CASE 


IF-GOTO 


Conditional  branch  to  named  CASE 


It  is  possible  to  store  FOCUS  transaction  processing 
commands  in  a  -File  -for  repetitive  use  or  execution  at  a 
later  time.  Any  CMS  -filename  and  filetype  can  be  used  to 
store  the  procedure^'  1-f  only  a  filename  is  provided,  a 
filetype  of  FOCEXEC  is  assumed  . 

With  the  Dialogue  Manager,  a  stored  procedure  may 
contain  variable  information  for  which  a  value  is  provided 
only  at  the  time  of  execution.  The  variables  can  be  used  to 
represent  data  as  numeric  constants,  dates,  or  to  conduct  a 
dialogue  by  prompting  the  operator  for  a  response.  The 
first  character  of  the  variable  must  be  an  ampersand. 

The  Dialogue  Manager  is  invoked  by  typing  the  FOCUS 
command  EXEC  followed  by  the  name  of  the  procedure. 
Together,  the  Dialogue  Manager  and  DDL  constitute  a 
semi -structured  programming  language.  Any  line  containing 
Dialogue  Manager  commands  or  GOTO  labels  must  begin  with  a 
dash.  The  EXEC  command  can  be  embedded  in  a  program  to  call 
another  module.  On  completion  of  the  called  module,  the 
Dialogue  Manager  returns  to  the  next  step  in  the  calling 
program. 

The  sequential  execution  of  one  Dialogue  Manager 
statement  after  another  can  be  altered  by  use  of  branching 
statements.  The  GOTO  command  can  be  used  separately,  in  an 
unstructured  mode,  to  branch  to  a  label  specified  elsewhere 

76 


in  the  program.  This  can  result  in  complicated  coding.  To 
eliminate  this  problem,  a  structured  programming  discipline 


must  be  maintained.  IF-GOTO  logic  and  labels  should  be  used 
only  for  sequential  or  closed  loop  execution.  Branching  is 
most  often  used  to  test  the  values  of  prompted  variables  and 
then  select  the  procedure  to  be  executed. 

Several  other  commands  and  labels  are  frequently 
used.  Messages  can  be  typed  from  a  stored  procedure  on 
Dialogue  Manager  lines  beginning  with  the  label  -TYPE. 
Variables  may  be  embedded  in  the  text  of  the  line.  -EXIT, 
-QUIT,  and  -RUN  are  three  labels  used  to  control  the 
execution  and  return  characteristics  of  a  FOCUS  stored 
procedure.  Individual  lines  of  a  stored  procedure  are 
stacked,  awaiting  execution,  until  either  the  label  -EXIT  or 
-Run  is  encountered.  An  implied  -EXIT  exists  after  the  last 
line  in  a  procedure.  When  either  an  implicit  or  explicit 
-EXIT  is  encountered  processing  of  lines  in  the  procedure  is 
ended  and  execution  of  the  stacked  lines  begins.  Control  is 
returned  to  the  next  higher  program  level  or  native  FOCUS. 
With  -QUIT,  the  return  characteristics  are  the  same  but  the 
stacked  lines  are  not  executed.  The  -RUN  label  exits  the 
procedure  and  executes  the  stacked  lines.  Processing 
resumes  at  the  line  following  -RUN^  Table  IX  summarizes  the 
effects  of  the  three  labels. 
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TABLE  IX 


1 


FOCUS  DIALOOUE  MANA6ER  LABELS 


I  LABEL 

+ - 

1 

\  -EXIT 
I 


EXECUTES  STORED  LINES 


RETURNS  TO 


YES 

> 


I 

Next  higher  program  level  I 
or  native  FOCUS  I 


I  I 

I  -QUIT  I 
I  I 


NO 


I 

Next  higher  program  level  I 
or  native  FOCUS  ) 


I  I 

I  -RUN  I 
+ - +. 


I 


YES 


Line  -following  -RUN 


If  a  stored  module,  called  by  another  procedure, 
does  not  contain  an  -EXIT  label  or  an  END  command,  the 
terminal  will  remain  open  for  interactive  processing.  When 
processing  or  queries  are  complete,  the  user  enters  QUIT  to 
return  to  the  calling  procedure.  This  technique  is  used  in 
the  design  of  the  data  dictionary  discussed  later  in  this 
chapter . 


B.  DATA  DICTIONARY 

During  the  design  phase  of  any  modular  application, 
standard  interfaces  are  specified.  This  can  be  accomplished 
through  communication  between  programmers  to  identify 
parameter  passing  requirements  such  as  global  variables. 
Verbal  communication  is  often  time  consuming,  error  prone, 
and  confusing.  Another  method  for  standardization  and 


control  is  ths  data  dictionary.  Using  this  method,  the  DBA 
can  specify  what  data  elements  and  relationships  are 
available  for  programmer's  use.  The  use  of  a  data 
dictionary  during  the  program  design  phase  is  one  specific 

application  of  standardization  and  sharing. 

;  , 

In  some  circles,  a  data  dictionary  is  considered  to  have 
only  limited  benefits  during  the  development  of  new  data 
processing  systems.  The  real  benefit  is  in  the  reduction  of 
maintenance  costs  CRef.  7tp.  903.  The  dividing  line  between 
development  and  maintenance  is  arbitrary.  It  is  sometimes 
hard  to  say  when  development  ends  and  maintenance  begins. 
An  explanation  for  this  opinion  is,  when  compared  to  the 
vast  benefits  gained  during  the  remainder  of  the  system  life 
cycle,  development  is  only  a  small  percentage  of  the  effort. 
Whatever  the  explanation,  the  judgment  is  in  error:  "A  data 
dictionary  can  be  of  particular  value  to  systems 
analysts/designers  in  the  three  phases  of  system 
development:  (1)  analysis,  (2)  design,  and 
(3)  implementation."  CRef.  10:p.  1053  It  is  acknowledged  in 
6overnment  and  private  industry  that  an  increase  in 
productive  time  and  money  expended  during  software 
development  can  significantly  reduce  total  life  cycle  costs. 

A  data  dictionary  can  be  an  invaluable  aid  during 
applications  program  development.  However,  not  all 
functions  of  the  FOCUS  DATA  DICTIONARY,  described  in  Chapter 
3,  are  required  or  even  useful  during  the  development  stage. 


Th«  most  bsneficial  dictionary  -functions  to  a  programmsr  are 
listed  below. 

*  reports  which  display  all  available  information  on 
programs,  data,  and  their  relationships 

*  automatic  dictionary  update  for  new  or  changed  Masters 
and  FOCEXECs.  ^ 

Reports  which  display  information  on  data  and  their 
relationships  can  yield  many  benefits.  This  one  function 
can  reduce  data  redundancy  and  develop  standards  by 
providing  the  system  designer  with  current  data  descriptions 
and  naming  conventions. 

It  is  possible,  with  the  FOCUS  46L,  to  implement  these 
useful  functions  without  the  expense  of  a  commercial  data 
dictionary  package.  Nevertheless,  a  basic  system 

development  dictionary  would  not  be  of  much  use  during  later 
life  cycle  stages. 

1 .  Planning 

It  is  necessary  to  plan  the  scope  and  objectives  of 
a  data  dictionary  before  construction  can  begin.  Here,  the 
purpose  of  the  dictionary  is  to  aid  in  the  development  of 
application  programs.  The  primary  objective  is  the 
Interactive  cross-referencing,  verifying,  and  updating  of 
data  about  data.  A  programmer  who  is  able  to  determine 
existing  relationships  and  names  from  a  data  dictionary  will 
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be  able  to  make  use  of  those  relationships  and  standard 
naming  conventions. 

The  proposed  system  is  narrow  in  scope.  It  is 
designed  as  a  FUCU8  DBMS  dependent  application.  Features 
include  ad  hoc  query  capability,  standard  reports  on 
metadata,  and  dictionary  maintenance. 

Although  automatic  dictionary  updates  are  useful  to 
the  programmer,  they  are  considered  non-essential  in  this 
case.  A  description  of  how  to  implement  an  automatic  update 
feature  is  given  in  the  design  phase. 

2.  Requirements  Definition 

The  outputs  from  the  design  data  dictionary  include 
the  following. 

*  FOCUS  file  definitions/descriptions 

*  Segment  definitions/descriptions 

*  Field  description/alias 

*  FOCUS  file  summary  report 

*  FOCUS  EXEC  descriptions 

*  Variable  names/descriptions 


*  Called/Called  by  analysis 


The  FOCUS  -filet  segment,  and  field  descriptions  and 
summary  report  are  used  to  determine  where  and  how  data  is 
stored.  All  the  information  contained  in  these  reports, 
with  the  exception  of  the  narrative  description,  can  be 

gleaned  from  the  FOCUS  Master  Description. 

> 

The  file  description  contains  the  file  name,  a 
narrative  description,  file  type,  and  number  of  segments. 
In  addition,  the  individual  or  organization  responsible  for 
maintenance  on  the  file  is  listed.  The  same  type 
information  is  contained  in  the  segment  and  field  reports. 

Details  on  FOCUS  EXECs  are  contained  in  variable, 
FOCUS  EXEC,  and  called/called  by  reports.  The  FOCUS  EXEC 
report  is  a  quick  reference  to  determine  the  purpose  of 
named  EXECs.  A  simple  naming  convention  is  imposed  through 
compliance  with  a  standard  pref i x~postf i x  routine.  The 
prefix  identifies  EXEC  purpose  and  the  postfix  specifies  a 
type.  For  example,  if  the  purpose  of  an  EXEC  were  to  add 
file  information,  it  would  be  named  ADDFILE.  If  the  purpose 
were  to  delete  EXEC  information,  it  would  be  named  DELEXEC. 
The  called/called  by  analysis  can  be  used  to  determine  the 
impact  of  a  change  to  a  specific  EXEC. 

The  ability  to  add,  change,  or  delete  items  in  the 
dictionary  is  called  dictionary  maintenance.  It  is 
accomplished  through  a  menu  driven  utility  for  either  FOCUS 
files  or  EXECs. 


Ad  hoc  queries  can  be  made  two  ways.  First,  by 
exiting  the  dictionary  and  returning  to  native  FOCUS,  the 
DML  can  be  used  to  make  queries.  The  disadvantage  is  that 
knowledge  of  data  structures  is  required  to  execute  dynamic 
Joins.  The  second  method  is  to  make  the  menu  selection  that 
best  answers  the  query,  then  at  the  end  of  execution,  make 
the  ad  hoc  query  prior  to  entering  quit.  This  technique  was 
discussed  earlier  in  this  chapter  under  the  Dialogue 
Manager. 


3.  Design 


Table  X  contains  the  data  necessary  to  meet  the 
requirements  above.  Two  FOCUS  Master  Files,  shown  in 
Table  XI,  were  defined  using  these  data  elements. 


TABLE  X 


DICTIONARY  DATA  ELEMENTS 


FOCUS  EXECS 


MASTER  FILES 


FOCUS  EXEC  name 
EXEC  purpose 
Variable  name 
Variable  format 
Variable  description 
File  used  by  EXEC 
EXEC  called  by  EXEC 


Master  File  name 
File  type 
File  description 
Segment  name 
Segment  parent 
Segment  type 
Segment  description 
Field  name 
A1  i  as 

Field  format 
Field  type 
Field  description 
key 


I 


TABLE  XI 


FOCUS  DESIGN  DICTIONARY  MASTER  FILES 


FOCUS 'MASTER  FILE  EDICT I ON 


F I LENAME-ED I CT I ON , SUFF I X -FOC 
SEGNAME-EXECS,SEGTYPE-S1 

FIELDNAME-EXEC  NAME  ,ALIAS-EN  ,F0RMAT-A8 
FIELDNAME-PURp5sE  , alias-does, F0RMAT-A25 
SEQNAME-VAR I ABLE , PARENT-EXECS , SEQT YPE-S 1 

FIELDNAME-VAR_NAME  ,ALIAS-VN  , FORMAT- AS  ,♦ 
FIELDNAME-VAR_FORMAT  , ALIAS-VFMT,F0RMAT-A5  ,♦ 

F I ELDNAME- VAR_DESCR I PT , AL I AS- VDES , FORMAT- A25  , « 

SEQNAME-F I LE.NAM , PARENT-EXECS , SEQT YPE-S 1 

FIELDNAMi-FILE.NAME  ,ALIAS-FLN  , FORMAT- AS  ,TYPE-I,* 
SEGNAME-CALLED , PARENT-EXECS , SEGTYPE-S 1 

FIELDNAME-CALLED.EXEC  ,ALIAS-CE  ,F0RMAT-A8 

FOCUS  MASTER  FILE  FDICTION 


I  F I LENAME-FD I CT I ON , SUFF I X -FOC 
\  SEGNAME-F I LES , SEQT YPE-S 1 

I  FIELDNAME»FILE_NAME  ,ALIAS=FLN  ,F0RMAT»A8  ,TYPE»I,* 

I  FIELDNAME»FILE_TYPE  , ALIAS»FTYP,F0RMAT-A3  ,f 

I  FIELDNAME-NUM_SEQS  ,ALIAS-NS  , FORMAT- II 

I  FIELDNAME-FILE_DESCRIP,ALIAS-FDES,F0RMAT-A25  ,» 

I  FIELDNAME»MAINTAINE_BY,ALIAS»FMAN,F0RMAT»A12 

1  SEGNAME-SEQMENTS , P ARENT-F I LES , SEQT YPE-S I 
I  FIELDNAME-SEQ_NAME  , ALIAS-SEGN,F0RMAT-A8  ,» 

I  FIELDNAME-CHILD_OF  , ALIAS-SPAR, FORMAT- AS  ,♦ 

!  FIELDNAME-SEQ  TYPE  , ALIAS-STYP ,F0RMAT«A3  ,♦ 

I  FIELDNAME»SEQ_DESCRIPT,ALIAS-SDES,F0RMAT=A25  ,♦ 

I  SEQNAME-F I ELDS , PARENT-SEGMENTS , SEQTYPE-S 1 
i  FIELDNAME-FIELD_NAME  ,ALIAS»FDN  ,F0RMAT-A12  ,♦ 

!  FIELDNAME-ALTERNATE  ,ALIAS-ALT  ,F0RMAT-A4  ,♦ 

!  FIELDNAME-FIELD_F0RMAT,ALIAS-FFMT,F0RMAT-A5  ,♦ 

I  FIELDNAME-FIELD_TYPE  , ALI AS-FDTP ,FORMAT-Al 

I  FIELDNAME-KEY  , ALI AS-  ,FORMAT=Al  ,♦ 

I  FIELDNAME-FIELD_DESCRI ,ALIAS»FDDE,F0RMAT=A25 

I 


Figures  S.2  and  S.3  depict  the  logical  FOCUS  structures 
derived  -from  the  Master  Files,  which  comprise  the  data 
storage  structures  for  the  dictionary.  FOCUS  source  code 
for  the  data  dictionary  and  sample  reports  are  contained  in 
Appendix  A. 

>  . 

FOCUS  has  the  ability  to  read  files  other  than  those 
it  creates  itself.  A  comma  delimited  file  is  one  in  which 
individual  fields  are  separated  by  a  comma.  A  FOCUS  Master 


+ - + 

I  EXECS  t 

I  01  SI  t 

I  #**«««»«»*»««*  I 

I  *EXEC_NAME  **  I 

I  *PURPaSE  **  ; 

I  *  ««  I 

I  *  I 

I  *  I 

I  »«**««***»*«*«*.  j 

I  *««#««****#'»««  I 

I  I  I 


+ - 

— 

— +- 

+ 

1 

I 

I 

I 

j 

I  VARIABLE 

I 

FILE 

_NAM 

I 

CALLED 

1 

02 

I  SI 

03 

I 

SI 

04 

I 

SI 

1 

************** 

♦♦♦♦♦♦♦♦*♦###* 

♦*♦***♦***♦♦■»* 

1 

1 

♦VAR 

.NAME  ♦♦ 

♦FILE 

.NAME 

♦*1 

♦CALLED 

EXEC 

♦♦ 

1 

♦VAR 

.FORMAT  ♦♦ 

♦ 

♦♦ 

♦ 

♦♦ 

1 

1 

♦VAR 

.DESCRIPT^^ 

♦ 

♦♦ 

♦ 

♦♦ 

1 

1 

♦ 

♦♦ 

♦ 

♦♦ 

♦ 

♦♦ 

1 

♦ 

♦♦ 

♦ 

♦♦ 

♦ 

♦♦ 

1 

I  ***************  *****««««****««  I 
**************  ***#*#***■»***•»  ******«***•»«*#  I 

I  I 
i  I 
+ - + 


Figure  5.2  Structure  of  Focus  File  Ediction 


FILES 
01  SI 

*«***•»««***«** 
*FILE_NAME  **I 
*FILE_TYPE  ** 
*NUM_SESS  ** 

*F I LE_DESCR I P** 

>  *  ** 
*»»****»*«■«»»** 
*«*«*«****«**« 

I 

I 

I 

I  SEGMENTS 
02  I  SI 

««*«««******«* 
*SEQ_NAME  ** 
*CHILD_0F  ** 
*SEQ_TYPE  ** 
*SEB_DESCRIPT** 

«««*■»#«******■»«■ 

I 

I 

I 

I  FIELDS 
03  I  SI 

************** 
*FIELD_NAME  ** 
♦ALTERNATE  ** 
♦FIELD.FORMAT** 
♦FIELD.TYPE  ** 

#  ** 
*************** 
************** 


Figure  5.3  Structure  of  Focus  File  Fdiction 


File  is  designed  as  a  comma  delimited  file  and  as  such 


be  read  directly  by  FOCUS 


The  design  data  dictionary  in  Appendix  A  can  be  made 
partially  active  by  taking  advantage  of  FOCUS  Master  Files 
comma  delimited  -form.  I-f  the  dictionary  Master  File  Mere 
assigned  a  file  type  of  external,  data  from  individual 

Master  Files  already  in  existence  could  be  made  available  to 

; 

the  user.  This  would  alleviate  the  need  to  enter 
information  into  the  dictionary  which  is  already  contained 
in  a  Master  File.  FOCUS  also  makes  provisions  for  a 
narrative  description  within  a  Master  File. 

Further  attempt  to  activate  the  design  dictionary 
is  not  recommended.  The  inhouse  development  of  an  active 
data  dictionary  can  be  a  costly  and  time  consuming  process. 
The  Director  of  Admissions  Office  does  not  have  the  assets 
available  to  accomplish  that.  It  is  recommended  that  a  Data 
Base  Administrator  be  assigned  from  the  Director  of 
Admissions  Office  and  that  the  FOCUS  Data  Dictionary  be 
purchased  and  implemented. 

C.  TRANSCRIPT  SUMMARY  APPLICATION 

The  planning  and  requirements  phase  of  the  transcript 
summary  application  were  covered  in  Chapter  2.  Table  XII 
lists  the  FOCUS  Master  File  descriptions.  The  resulting 
logical  structures,  shown  in  Figures  5.4,  5.5,  and  5.6,  were 
dictated  by  the  characteristics  of  the  external  files 
supplied  by  the  Naval  Academy. 


TABLE  XII 


TRANSCRIPT  SUMMARY  APPLICATION  MASTER  FILES  I 

FOCUS  MASTER  FILE  ADM I SS 10  I 

FILENAME-ADMISSIO,SdFFIX-FOC  I 

SEGNAME»STUDENT,SEGTYPE-iSl  I 

FIELDNAME«STUD_ID  ,ALIAS-SID  ,F0RMAT=A7  I 

FIELDNAME-STUD_NAME  ,ALIAS-SN  ,F0RMAT»A17  ,♦  I 

FIELDNAME-SOC_iEC_NUM  ,ALIAS«SSN  ,F0RMAT-A10  ,♦  I 

FIELONAME»MAJOR  ,ALIAS«MAJ  ,F0RMAT-A4  I 

FIELDNAME-SEX  , ALIAS-SEX  ,F0RMAT-A2  t 

FIELDNAME-NATIONALITY  ,  ALIAS-RACE, FORMAT*^  AS  ,♦  I 

SEGNAME-COURSE , SEGT YPE-S 1  I 

FIELDNAME-COURSE_ID  ,ALIAS-CID  ,F0RMAT-A6  ,♦  I 

FIELDNAME-LETTER  GRADE , ALIAS-LG  ,F0RMAT-A2  I 

FIELDNAME-SEMESTER  ,ALIAS-WHEN,F0RMAT-A3  ,«  I 

FOCUS  MASTER  FILE  AVAIL  I 

FILENAME»AVAIL,SUFFIX-FOC  I 

SEGNAME-DESCR I PT, SEGT YPE-S 1  t 

FIELDNAME-COURSE  ID  ,ALIAS-CID  ,F0RMAT-A6  ,TYPE»I,»I 
FIELDNAME-CREDIT_HOURS,ALIAS-CHRS,FORMAT-Il  ,♦  I 

FOCUS  MASTER  FILE  REQ  I 


i 

JFILENAME-REa,SUFFIX-FOC  I 
I  SEGNAME-DESCR I PT,SEGTYPE-S1  I 
I  FIELDNAME»COURSE_ID  ,ALIAS-CID  ,F0RMAT»A6  ,TYPE=I,#I 
I  FIELDNAME»SUBJ_AREA  ,ALIAS»SA  ,F0RMAT-A7  ,♦  I 
I  I 
+ - + 


The  source  code  and  sample  output  for  a  prototype 
application  that  summarizes  transcript  information  are  given 
in  Appendix  B.  The  prototype  can  be  modified  to  read  data 
from  the  fixed  format  external  file  described  in  Chapter  2. 


STUDENT 
01  SI 

■»*«**«**«*«*** 
*STUD_ID  *♦ 

*STUD_NAME  ** 
*S0C_iEC_NUM  *♦ 
*MAJ0R  ** 

«■*«•*««**««***«* 

««***«**««««** 

I 

I 

I 

I  COURSE 
02  I  SI 
«*«#»«#■»**«««* 
♦COURSE. ID  ** 

♦LETTER  GRADE^^ 
♦SEMESTER  ♦♦ 


♦««♦♦♦«♦««»«*«* 

♦♦♦♦♦♦♦♦♦«♦♦*» 


Figure  5.4  Structure  o-f  Focus  File  Adtnissio 


The  external  file  contains  a  group  of  adjacent  fields  that 
are  repeated  in  the  same  record.  <ie.  Course  information  is 
repeated  numerous  times  for  each  student.)  Such  a  structure 
can  be  described  to  FOCUS  by  assigning  the  non-repeating 
portion  to  one  segment,  and  the  repeating  group  to  another, 
which  is  its  descendent.  By  assigning  a  Segment  attribute 
of  VARIABLE  to  the  repeating  group,  FOCUS  is  Informed  that 
the  length  of  the  physical  external  file  varies.  The  number 


dictionary  can  aid  in  prografflmsr  a-f f ecti vsnass  and  provida 
managament  with  more  e-F-f active  control  over  data. 

B.  BENEFITS 

Even  the  most  baisic  form  of  a  data  dictionary,  when 
properly  implemented,  can  be  of  great  use  during  the  program 
development  cycle.  Conversely,  poor  design,  implementation, 
or  usa  will  make  problems  like  data  integrity  and  redundancy 
even  worse. 

The  major  benefits  derived  from  use  of  the  data 
dictionary  (Appendix  A)  during  the  design  phase  of  the 
transcript  summary  application  (Appendix  B)  are  listed 
belowi 

*  Reduced  data  redundancy 

*  Enhanced  data  integrity 

*  Documentation  of  existing  relationships 

*  Simplified  system  maintenance 

*  Highlighted  standard  naming  conventions 

*  Provided  data  element  reference 

Benefits  derived  from  a  data  dictionary  are  proportional 
to  its  size.  Since  the  transcript  summary  program  spanned 
only  three  FOCUS  files,  it  is  hard  to  say  that  the  data 


dictionary  provided  any  great  advantage.  Nevertheless, 
access  to  data  elements  and  their  logical  structure  enhanced 
the  programmer's  ability  to  locate  and  reduce  data 
redundancy. 

Implementation  o-f  a  data  dictionary  requires  the 
standardization  o-f  data  items.  For  a  large  existing  system 
in  an  organization  Mith  multiple  departments,  this  can  be 
complex.  Even  in  the  simple  application  discussed  here,  the 
standardization  o-f  data  items  greatly  contributes  to  long 
range  data  integrity. 

During  the  design  o-f  the  transcript  application, 
in-formation  on  which  programs  use  the  same  data  type  and  how 
they  relate  was  required.  This  is  in  essence  a  limited  view 
of  the  logical  data  structure  and  relationships.  It  is 
required  for  the  proper  access  of  required  data,  using 
dynamic  joining  when  necessary. 

Maintenance  can  be  defined  many  ways.  Regardless  of 
whether  it  is  considered  as  modifications  after  delivery  or 
after  the  first  successful  execution,  the  benefits  of  the 
data  dictionary  are  the  same.  If  the  dictionary  is  updated 
along  with  program  modifications,  it  becomes  consistent, 
reliable  documentation  that  is  essential  for  program 
mai ntenance. 

At  a  basic  level ,  a  data  dictionary  is  composed  of  data 
elements  and  their  description.  This  reference  list  can  be 
used  to  evaluate  the  impact  of  proposed  changes,  prior  to 


their  occurrence.  By  its  nature  it  provides  a  way  to 
highlight  standard  naming  conventions.  New  data  elements  to 
be  entered  in  the  dictionary  must  be  consistent  with 
existing  naming  conventions. 

C.  SYNOPSIS 

This  thesis  described  the  design,  implementation,  and 
use  of  a  basic  data  dictionary.  The  design  and  development 
of  an  undergraduate  transcript  summary  application  for  the 
Director  of  Admissions  at  NPS  was  used  to  evaluate  the 
benefits  of  the  data  dictionary.  The  concepts  of  dependent 
and  independent  dictiona'^ies  were  discussed  and  the 
fundamental  principles  were  applied  to  the  dictionary 
design.  A  comparison  of  three  data  base  models  and  a 
summary  of  commercial  data  base  management  systems  and  data 
dictionaries  was  made.  The  advantages  and  disadvantages  in 
the  development  and  use  of  46L5  were  discussed. 

As  the  scope  of  data  base  applications  in  an 
organization  grows,  the  tendency  is  to  define  new  data 
elements  and  structures  rather  than  interpret  the  data  that 
already  exists.  The  data  dictionary  is  a  tool  that  provides 
programmers  with  access  to  standard  data  items  and 
structures.  It  is  the  responsibility  of  the  DBA  to  ensure 
that  these  standards  are  maintained.  Management,  users,  and 
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data  processing  personnel  must  all  be  committed  to  this 
standardization  concept  before  any  benefits  can  be  realized. 
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APPENDIX  A 


DATA  DICTIONARY  SOURCE  CODE 


NODULEi  HAINHENU  FOCEXEC 
WRITTEN  BYt  BOB  REPP 
C^LEO  BYt  PROJNENU  FOCEXEC 
CALSt  HANTHENU.FILEHENU.EXECHENU  FOCEXEC 
PURPOSE!  MAIN  MENU  FOR  THE  DATA 
DICTIONARY 


INFORHATION  ON  FOCUS  FILES  . .  <F> 

INFORHATION  ON  FOCEXECS  .  <E> 

DICTIONARY  HAINTENANCE  . .  <N> 

QUIT  . <Q> 


SET  NSe-OFF 
-CRTCLEAR 
-BE8IN 
-CRTCLEAR 

-TYPE  THIS  IS  THE  HAIN  HENU  FOR  THE  DATA  DICTIONARY 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE  r‘"RATR‘RERO . . . I  . 

-TYPE  I 
-TYPE  ! 

-TYPE  I  INFORHATION  ON  FOCUS  FILES  . .  <F> 

-TYPE  I  INFORHATION  ON  FOCEXECS .  <E> 

-TYPE  I  DICTIONARY  HAINTENANCE  . .  <H> 

-TYPE  I  QUIT  . <Q> 

-TYPE  I 
-TYPE  i 
-TYPE 
-TYPE 
-TYPE 

-PROHPT  ItSELECT.  WHAT  IS  YOUR  CHOICE? 

ELSE  IF  tiltlEf  ii  T'  eafB  likin 

-  ELSE  IF  IeSELECT  IS  H'  SOTO  HAINT 

-  ELSE  IF  ((SELECT  IS  Q'  SOTO  EXIT 
ELSE  SOTO  BESINi 

-FILEHENU 
EXEC  FILEHENU 
-RUN 

-CRTCLEAR 
-SOTO  BE8IN 
-EXECHENU 
EXEC  EXECHENU 
-RUN 

-CRTCLEAR 
-SOTO  BESIN 
-HAINT 

EXEC  HANTHENU 
-RUN 

-CRTCLEAR 
-SOTO  BESIN 
-EXIT 


nOOULEi  KANTHENU  FOCEXEC 

WRITTEN  BYt  BOB  REPP 

CALLED  BYt  HAINHENU  FOCEXEC 

CALLSi  HODIFILE  FOCEXEC.  HOOIEXEC  FOCEXEC 

PURPOSE!  DICTIONARY  MAINTENANCE  MENU 


MODIFY  FILE  DATA  .  <1> 

MODIFY  EXEC  DATA .  <2> 

EXIT  (to  oain  oonu)  .......  <X> 


-CRTCLEAR 

-FIRST  j 

-TYPE  THIS  IS  THE  MAINTENANCE  MENU  FOR  THE  DATA  DICTIONARY 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE  ^“•RAIII|■RERO . . ! . . . . 

-TYpI  I  r"B«IRTERARCE‘HEHO - i 

-TYPE  I  I  . 

-TYPE  I  I 

-TYPE  I  I  MODIFY  FILE  DATA  .  <1> 

-TYPE  I  I  MODIFY  EXEC  DATA .  <2> 

-TYPE  I  I  EXIT  (to  oain  oonu)  .  <X> 

TYPE  I  I 

TYPE  “I 
TYPE  I 

TYPE  . . 

TYPE 
TYPE 

-PROMPT  tiWHICH.  WHAT  IS  YOUR  CHOICE?. 

-IF  liNHICH  EO  I  SOTO  HODIFILE 

-  ELSE  IF  tiHHICH  ES  2  SOTO  HODIEXEC 

-  ELSE  IF  liNHICH  IS  'X'  SOTO  EXIT 

-  ELSE  60T0  FIRST] 

-HODIFILE 
EXEC  HODIFILE 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-HODIEXEC 
EXEC  HODIEXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
EXIT 
OFi 


I 


HOOULEl  HOOIEXEC  FOCEXEC 

WRITTEN  BYi  BOB  REPP 

CALLED  BYi  HANTHENU  FOCEXEC 

CALLSi  AOOEXEC,  CH6EXEC.  DELEXEC  FOCEXEC 

PURPOSEi  EXEC  NAINTENANCE  MENU 


-CRTCLEAR 

-PRIHE 

-TYPE  THIS  IS  THE  EXEC  NAINTENANCE  HENU  FOR  THE  DATA  DICTIONARY 
-TYPE  ^ 

-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-PRONPT 
-IF 

-  ELSE 

-  ELSE 

-  ELSE 


■MTR"I1EH0 . . J . 

■■"EXEC'RAIRTERARCE'RERO - 1 . 

ADO  EXEC  INFORMATION .  <1> 

UPDATE  EXEC  INFORMATION  ...  <2> 

DELETE  EXEC  INFORMATION  ...  <3> 

EXIT  <to  aain  aanu)  .......  <X> 


tiNHAT.  WHAT 
IcNHAT  EQ 
IF  tiHHAT  EQ 
IF  kWHAT  EQ 
IF  tiNHAT  IS 
-  ELSE  SOTO  PRIMEi 
-ADDEXEC 
EXEC  ADDEXEC 
-RUN 

-CRTCLEAR 
-SOTO  PRIME 
-CHSEXEC 
EXEC  CHSEXEC 
-RUN 

-CRTCLEAR 
-SOTO  PRIHE 
-DELEXEC 
EXEC  DELEXEC 
-RUN 

-CRTCLEAR 
-SOTO  PRIHE 
-EXIT 


IS 

1 

2 
3 

'X 


YOUR  ANSWER?. 
SOTO  ADDEXEC 
SOTO  CHSEXEC 
SOTO  DELEXEC 
SOTO  EXIT 


MODULE!  ADDEXEC  FOCEXEC 

WRITTEN  BYi  BOB  REPP 

CALLED  BYi  NODIEXEC  FOCEXEC 

CALLS!  ADD1EXEC.ADD2EXEC,ADD3EXEC.ADD4EXEC 

PURPOSE!  ADD  MENU  UNDER  DICTIONARY  MAINTENANCE 


-FIRST 

-CRTCLEAR 

-TYPE  THIS  IS  THE  ADD  HENU  UNDER  DICTIONARY  MAINTENANCE 

-TYPE 

-TYPE 

-TYPE 
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ADO  NEW  EXECS  .  <i> 

ADD  VARIABLES  TO  EXISTINO  EXEC  .  <2> 

ADD  RASTER  FILES  USED  BY  AN  EXIST1N6  EXEC  ..  <3> 

ADD  EXECS  CALLED  BY  AN  EXISTIN6  EXEC  .  <4> 

EXIT  . . <X> 


-TYPE 

-TYPE  I  "'HSWWHO . T._ 

-TYpI  I  l"■■MIHTEWRCE■flEf^O . I 

-TYpI  i  !  I — RDD’ElTECTflFORMTIflfl - 

-TYPE  I  I  I 

-TYPE  III  ADO  NEH  EXECS  . 

-TYPE  III  ADD  VARIABLES  TO  EXI 

-TYPE  III  ADD  RASTER  FILES  USE 

-TYPE  I  I  ADD  EXECS  CALLED  BY 

-TYPE  l_l  EXIT  . . 

-TYPE  I  ^ 

-TYPE  I 

-TYPE  . . . 

-PRORPT  tiCHOOSE.  HHAT  IS  YOUR  CHOICE?. 
-IF  tiCHOOSE  EO  1  SOTO  AOOIEXEC 

-  ELSE  IF  tiCHOOSE  EO  2  SOTO  ADD2EXEC 

-  ELSE  IF  tiCHOOSE  EQ  3  60TQ  A0D3EXEC 

-  ELSE  IF  tiCHOOSE  EB  4  SOTO  ADD4EXEC 

-  ELSE  IF  tiCHOOSE  IS  X'  SOTO  EXIT 

-  ELSE  SOTO  FIRST! 

-AODIEXEC 

EXEC  ADDIEXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-A0D2EXEC 
EXEC  AD02EXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-A0D3EXEC 
EXEC  A0D3EXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-A0D4EXEC 
EXEC  AD04EXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-EXIT 


I 


NOOULEl  AOOIEXEC  FOCEXEC 

NRITTEN  BYt  BOB  REPP 

CALLED  BYi  ADOEXEC  FOCEXEC 

CALLSi  EDICTION  FOCUS,  EDICTION  RASTER 

PURPOSEi  ADD  NEN  EXECS  TO  DATABASE 


-CRTCLEAR 

RODIFY  FILE  EDICTION 
PRORPT  EXEC  RARE 
RATCH  EXEC.RARE 

ON  RATCH  REJECT 
ON  NOHATCH  PRORPT  PURPOSE 
NOHATCH  INCLUDE 
DATA 
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HODULEl  A0D2EXEC  FOCEXEC 
MRITTEN  BYi  BOB  REPP 
CALLED  BYi  AODEXEC  FOCEXEC 
CALLBi  EOICTION  FOCUS.  EDICTION  RASTER 
PURPOSE!  ADD  VARIABLES  TO  THE  DATA 
DICTIONARY  FOR  EXECS  ALREADY  IN  THE 
DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  EOICTION 
PROHPT  EXEC  NAHE  VAR  NAME 
HATCH  EXEC  RARE  ~  . 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  VAR  NAHE 

ON  HATCH  REJECT 

ON  NOHATCH  PROHPT  VAR  FORHAT  VAR  DESCRIPT 
ON  NOHATCH  INCLUDE  ~ 

DATA 


HODULEl  A003EXEC  FOCEXEC 
NRITTEN  BYi  BOB  REPP 
CALLED  BYi  AODEXEC  FOCEXEC 
CALLSi  EDICTION  FOCUS.  EDICTION  RASTER 
PURPOSEi  ADD  RASTER  FILES.  USED  BY  AN 
EXEC,  TO  THE  DATA  DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  EDICTION 
PROHPT  EXEC.NAHE  FILE.NAHE 
HATCH  EXEC.RAHE 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  FILE  NAHE 

ON  HATCH  REJECT 
ON  NOHATCH  INCLUDE 

DATA 


HODULEl  A004EXEC  FOCEXEC 
NRITTEN  BYi  BOB  REPP 
CALLED  BYi  AODEXEC  FOCEXEC 
CALLSi  EDICTION  FOCUS,  EDICTION  RASTER 
PURPOSEi  ADO  EXECS  TO  THE  DATA 
DICTIONARY  THAT  ARE  CALLED  BY  AN  EXEC 
ALREADY  IN  THE  DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  EDICTION 
PROHPT  EXEC  NAHE  CALLED  EXEC 
NATCH  EXEC  RARE 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  CALLED  EXEC 

ON  HATCH  REJECT 
ON  NOHATCH  INCLUDE 


HODULEt  CH8EXEC  FOCEXEC 
WRITTEN  BVi  BOB  REPP 
CALLED  BYt  HODIEXEC  FOCEXEC 
CALLSi  CHBIEXEC,  CHB2EXEC  FOCEXEC 
PURPOSE!  UPDATE  EXEC  HENU  UNDER 
DICTIONARY  NAINTENANCE 


■RAIRTENARCE'RERO . . I„ 

■■■OPDATE'EXEC'TRFORRATTOR”  I 


UPDATE  VARIABLE  FORHAT  OR  DESCRIPTION 

UPDATE  EXEC  PURPOSE  . 

EXIT  . 


-HENU 

-CRTCLEAR 

-TYPED  THIS  IS  THE  UPDATE.  HENU  UNDER  DICTIONARY  NAINTENANCE 
-TYPE  ^ 

-TYPE 

-TYPE 

-TYPE 

-TYPE  I  ""RATR'RERO .  T _ _ 

-TYPE  I  ^■■HA1RTENARCE■RER0 . . I . 

-TYpI  !  1  r"OPDATE'EXEC‘TRFORRATTOR”l 

-TYPE  I  I  I  . . 

-TYPE  I  I  I  UPDATE  VARIABLE  FORHAT  OR  DESCRIPTION  .... 

-TYPE  I  I  I  UPDATE  EXEC  PURPOSE  . 

-TYPE  I  I  I  EXIT  . 

-TYPE  "I  I 
-TYPE  I  I 
-TYPE  "I 

-PROHPT  iiCH0rcE:‘BflAT‘is"700R'Cfi0rcE?: . . 

-IF  tcCHOICE  EQ  1  BOTO  CHBIEXEC 

-  ELSE  IF  tiCHOICE  EQ  2  BOTO  CHB2EXEC 

-  ELSE  IF  tiCHOICE  IS  'X'  BOTO  EXIT 

-  ELSE  BOTO  HENUl 
-CHBIEXEC 

EXEC  CHBIEXEC 
-RUM 

-CRTCLEAR 
-BOTO  HENU 
-CHB2EXEC 
EXEC  CHB2EXEC 
-RUN 

-CRTCLEAR 
-BOTO  HENU 
-EXIT 


HODULEi  CHBIEXEC  FOCEXEC 
WRITTEN  BYi  F  )  REPP 
CALLED  BYt  Ch  cXEC  FOCEXEC 
CALLSi  EDICTION  FOCUS,  EDICTION  RASTER 
PURPOSE!  UPDATES  VARIABLE  INFORMATION 
IN  THE  DATA  DICTIONARY 


-CRTCLEAR 

MODIFY  FILE  EDICTiON 
PROHPT  EXEC  NAME  VAR  NAME 
HATCH  EXEC  RAHE 

ON  noratch  reject 

ON  NATCH  CONTINUE 
HATCH  VAR  NAME 

ON  HATCH  PROHPT  VAR  FORHAT  VAR  DESCRIPT 
ON  HATCH  UPDATE  VAR“FORHAT  VAR'DESCRIPT 
ON  NOHATCH  REJECT  ~ 


’  b  •  -  •  .  • 


*.  •*..  ’•'-X 


DATA 


HODULEt  CH62EXEC  FOCEXEC 
WRITTEN  BYi  BOB  REPP 
CALLED  BVt  CH6EXEC  FOCEXEC 
CALLSi  EDICTION  FOCUS,  EDICTION  RASTER 
PURPOSEi  UPDATES  EXEC  PURPOSE  IN  THE 
DATA  DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  PURPOSE  ; 
HATCH  EXEC.RAHE  ^ 

ON  NORATCH  REJECT 
ON  NATCH  UPDATE  PURPOSE 

DATA 


NODULEl  DELEXEC  FOCEXEC 
WRITTEN  BYl  BOB  REPP 
CALLED  BYt  NODIEXEC  FOCEXEC 
CALLSt  DEL1EXEC,DEL2EXEC,DEL3EXEC,DEL4EXEC 
PURPOSEi  EXEC  D^ETE  MENU  UNDER 
DICTIONARY  MAINTENANCE 


•RBTR'RENO’ 


I 


I 


I 


I 


I 


'RBIRTeNARCE'REND' 


! 


-FIRST 

-CRTCLEAR 

-TYPE  THIS  IS  THE  DELETE  MENU  UNDER  DICTIONARY  MAINTENANCE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 

'prompt  fcWHrcflr'RflRTTS'YooR'Cfloice?: 


■DECETE‘EIEC”IRFORRBTTOR"” I . 


DELETE  ALL  INFORMATION  ON  AN  EXEC .  <1> 

DELETE  INFO  ON  A  VARIABLE  USED  IN  AN  EXEC  ....  <2> 
DELETE  INFO  ON  A  MASTER  FILE  USED  BY  AN  EXEC  .  <3> 

DELETE  INFORMATION  ON  A  CALLED  EXEC  .  <4> 

EXIT  .  <X> 


-IF 


tiNHICH  EQ  1  SOTO  DELIEXEC 
ELSE  IF  IcWHICH  EQ  2  SOTO  DEL2EXEC 

ELSE  IF  liNHICH  EQ  3  SOTO  DEL3EXEC 

ELSE  IF  ItWHICH  EQ  4  SOTO  DEL4EXEC 

-  ELSE  IF  IcWHICH  IS  X  SOTO  EXIT 

ELSE  SOTO  FIRST; 

-DELIEXEC 
EXEC  DELIEXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-DEL2EXEC 
EXEC  DEL2EXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-DEL3EXEC 
EXEC  DEL3EXEC 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 


-0EL4EXEC 
EXEC  DEL4EXEC 
-RUN 

-CRTCLEAR 
-60T0  FIRST 
-EXIT 


t  NOOULEi  OELIEXEC  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  C^LEO  BY:  DELEXEC  FOCEXEC 

*  CALLS:  EDICTION  FOCUS,  EDICTION  RASTER 

t  PURPOSE:  DELETE  ALL  INFORNATION  IN  THE 

*  DATA  DICTIONARY  ON  AN  EXEC 

*«*#**««*•*««« t«f #**««***«***«##•»****« t«*t •#«**«#*##«**#***«####»•#* 

-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME 
MATCH  EXEC  NAME 

ON  MATCH  DELETE 
ON  NOMATCH  REJECT 

DATA 


MODULE:  DEL2EXEC  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  DELEXEC  FOCEXEC 
CALLS:  EDICTION  FOCUS,  EDICTION  MASTER 
PURPOSE:  DELETE  ALL  INFORMATION  IN  THE 
DATA  DICTIONARY  ON  A  VARIABLE  USED 
IN  AN  EXEC 


i 

-CRTCLEAR 

MODIFY  FILE  EDICTION 

PROMPT  EXEC  NAME  VAR  NAME 

MATCH  EXEC  NAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  VAR  NAME 

ON  MATCH  DELETE 
ON  NOMATCH  REJECT 

DATA 


•*f #«•#«#*•*••***# **«#«#§#•# t «§#*«# ft 

MODULE:  DEL3EXEC  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  DELEXEC  FOCEXEC 
CALLS:  EDICTION  FOCUS,  EDICTION  MASTER 
PURPOSE:  DELETE  INFORMATION  IN  THE 
DICTIONARY  ON  MASTER  FILES  CALLED 
BY  AN  EXEC 

#«**#***•« t*«f 


-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  FILE  NAME 
MATCH  EXEC  NAME 

ON  MATCH  CONTINUE 
ON  NOMATCH  REJECT 
MATCH  FILE  NAME 

ON  match  delete 

ON  NOMATCH  REJECT 

DATA 
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•t.  ■  a  -  r- 


HODULEi  DEL4EXEC  FOCEXEC 

WRITTEN  BYt  BOB  REPP 

CALLED  BYi  DELEXEC  FOCEXEC 

CALLSt  EDICTION  FOCUS.  EDICTION  RASTER 

PURPOSE!  DELETE  INFORMATION  IN  THE 

DICTIONARY  ON  AN  EXEC  CALLED  BY  AN  EXEC 


-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  CALLED  E.XEC 
MATCH  EXEC  NAME  ' 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
MATCH  CALLED  EXEC 

ON  MATCH  DELETE 
ON  NOMATCH  REJECT 

DATA 


MOOULEt  HODIFILE  FOCEXEC 

WRITTEN  BYi  BOB  REPP 

CALLED  BYt  MANTHENU  FOCEXEC 

CALLSi  ADDFILE.  CHSFILE.  DELFILE  FOCEXEC 

PURPOSE!  MASTER  FILE  MAINTENANCE  MENU 


-CRTCLEAR 

-PRIME 

-TYPE  THIS  IS  THE  FILE  MAINTENANCE  MENU  FOR  THE  DATA  DICTIONARY 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 

-PROMPT  liNHAT.  WHAT  IS  YOUR  ANSWER?. 

-IF  IcWHAT  IS  1  SOTO  ADDFILE 

-  ELSE  IF  ItWHAT  IS  2  SOTO  CHSFILE 

-  ELSE  IF  liWHAT  IS  3  SOTO  DELFILE 

-  ELSE  IF  tiWHAT  IS  'X'  SOTO  EXIT 

-  ELSE  SOTO  PRIME) 

-ADDFILE 
EXEC  ADDFILE 
-RUN 

-CRTCLEAR 
-SOTO  PRIME 
-CHSFILE 
EXEC  CHSFILE 
-RUN 

-CRTCLEAR 
-SOTO  PRIME 
-DELFILE 
EXEC  DELFILE 


■BRTR'HEHO . 

•■■FTCE'MINTENRRCE’HERO' 


ADD  FILE  INFORMATION .  <1> 

UPDATE  FILE  INFORMATION  ...  <2> 
DELETE  FILE  INFORMATION  ...  <3> 
EXIT  (to  aain  acnu)  .  <X> 


I 
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-RUN 

-CRTCLEAR 
-GOTO  PRIME 
-EXIT 


tf •*«*«»«««*««*••*««««**«*««**#««««*•«*«*«##«**#«**«#*#*«*#**#«#*#«« 

MODULE:  ADDFILE  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  MODIFILE  FOCEXEC 

CALLS:  ADD1FILE,ADD2FILE.ADD3FILE 

PI^POSE:  ADD  MENU  UNDER  DICTIONARY  MAINTENANCE 


##«•#«««#*••*«***••*«****••«««•#««*«*««««•*•****#«*#****#««•*«•*##«## 

-CRTCLEAR 

-TYPE  THIS  IS  THE  ADO  MENU  UNDER  DICTIONARY  MAINTENANCE 
-FIRST 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 

-PROMPT  tiCHOOSE.  WHAT  IS  YOUR  CHOICE?. 

-IF  tiCHOOSE  EQ  1  SOTO  AODlFILE 

-  ELSE  IF  tiCHOOSE  EQ  2  GOTO  ADD2FILE 

ELSE  IF  tcCHOOSE  EQ  3  GOTO  ADD3FILE 

ELSE  IF  liCHOOSE  IS  'X'  GOTO  EXIT 

ELSE  GOTO  FIRST} 

-ADDIFILE 
EXEC  ADDIFILE 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-A002FILE 
EXEC  ADD2FILE 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-ADD3FILE 
EXEC  AD03FILE 
-RUN 

-CRTCLEAR 
-GOTO  FIRST 
-EXIT 


MODULE:  ADDIFILE  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  ADDFILE  FOCEXEC 
CALLS:  FDICTION  FOCUS  .  FDICTION  MASTER 
PURPOSE:  ADO  NEW  MASTER  FILES  TO  DATABASE 
DICTIONARY 

*#**####******#*«####*#*#*##«#f*f****t#*##t*##***#**####*f §*#♦#♦*##* 


■■HAIR-RENO - 1. 

I  ■■■FTCE‘HAINTERANCE"RERO‘“"' 
"ADD'FTCE'IRFORRATTOR"' 


ADD  NEW  MASTER  FILES  .  <1> 

ADD  SEGMENTS  TO  A  MASTER  FILE  .  <2> 

ADD  FIELDS  TO  A  SEGMENT  . .  <3> 

EXIT  .  <X> 
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-CRTCLEAR 

HOOIFY  FILE  FOICTION 
PROHPT  FILE.NAHE 
NATCH  FILE  RARE 

ON  HATCH  REJECT 

ON  NOHATCH  PROHPT  FILE  TYPE  NUN.SE68 
ON  NONATCH  PROHPT  FILE  DESCRIP  RAINTAIN  BY 
ON  NONATCH  INCLUDE 


nS^LEi  ADD2FILE  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYt  ADDFILE  FOCEXEC 
CALLSi  FDICTION  FOCUS,  FDICTION  RASTER 
PURPOSEt  ADD  SE6HENTS  TO  THE  DICTIONARY 
FOR  RASTER  FILES  IN  THE  DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  FDICTION 
PROHPT  FILE  NAHE  SEO  NAHE 
HATCH  FILE  RARE 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  SEO  NAHE 

ON  HATCH  REJECT 

ON  NOHATCH  PROHPT  CHILD  OF  SEO.TYPE  SE6.DESCRIPT 
ON  NONATCH  INCLUDE 

DATA 


HODULEi  ADD3FILE  FOCEXEC 
NRITTEN  BYi  BOB  REPP 
CALLED  BYt  ADDFILE  FOCEXEC 
CALLSt  FOICTION  FOCUS.  FDICTION  RASTER 
PURPOSEt  ADOS  FIELDS  tO  THE  DATA 
DICTIONARY  FOR  SE6HENTS  IN  THE 
DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  FDICTION 

PROHPT  FILE  NAHE  SEO  NAHE  FIELD  NAHE 

HATCH  FILE  RARE 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  SEO  NAHE 

ON  NATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  FIELD  NAHE 

ON  HATCH  REJECT 

ON  NOHATCH  PROHPT  ALTERNATE  FIELD^FORHAT  FIELD.TYPE 
ON  NOHATCH  PROHPT  KEY  FIELD  DESCRl 


ON  NOHATCH  INCLUDE 


HODULEi  DELFILE  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYt  HODIFILE  FOCEXEC 
CALLSt  DEL1FILE,DEL2FILE,DEL3FILE  FOCEXEC 
PTRCOSEt  DELETE  FILE  HENU  UNDER 
DICTIONARY  HAINTENANCE 


-FIRST 


~CRTCLEAR 

-TYPE  THIS  IS  THE  DELETE  HENU  UNDER  DICTIONARY  HAINTENANCE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE  I - MIR“HEIIO . . ! . . . . 

-TYpI  1  r”FTCE'HATRTER»RCE"HERD - 1 . . 

-TYpI  1  1  ^■■»DD"FICE■TRFORHRTIQR - i 

-TYPE  III  i  . . 

-TYPE  I  i  I  DELETE  ALL  INFO  ON  A  RASTER  FILE  . 


DELETE  ALL  INFO  ON  A  RASTER  FILE 
DELETE  ALL  INFO  ON  A  SE8RENT  .... 

DELETE  ALL  INFO  ON  A  FIELD  . 

EXIT  . 


-TYPE  I  I  I  DELETE  ALL  INFO  ON 

-TYPE  I  !  I  DELETE  ALL  INFO  ON 

-TYPE  "I  I  EXIT  . 

-TYPE  I  I 

-TYPE  'I 

-TYPE  I  . 

-TYPE 

-PRORPT  tiNHICH.  NHAT  IS  YOUR  CHOICE?. 
-IF  tiNHlCH  EQ  1  SOTO  DELIFILE 

-  ELSE  IF  liNHICH  EQ  2  SOTO  0EL2FILE 

-  ELSE  IF  tiNHICH  EQ  3  SOTO  DEL3FILE 

-  ELSE  IF  liNHICH  IS  X  SOTO  EXIT 

-  ELSE  SOTO  FIRSTi 

-DELIFILE 

EXEC  DELIFILE 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-DEL2FILE 
EXEC  DEL2FILE 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-DEL3FILE 
EXEC  0EL3FILE 
-RUN 

-CRTCLEAR 
-SOTO  FIRST 
-EXIT 


RODULEl  DELIFILE  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYl  DELFILE  FOCEXEC 
CALLS!  FDICTION  FOCUS.  FDICTION  RASTER 
PURPOSE!  DELETE  ALL  INFORRATION  IN  THE 
DATA  DICTIONARY  ON  A  RASTER  FILE 


-CRTCLEAR 

RODIFY  FILE  FDICTION 
PRORPT  FILE  RARE 
HATCH  FILE  BARE 

ON  HATCH  DELETE 
ON  NONATCH  REJECT 

DATA 


-  . 
S." 


HODULEt  0EL2FILE  FOCEXEC 
WRITTEN  BVl  BOB  REPP 
CALLED  BYt  DELFILE  FOCEXEC 
CALLS!  FOICTION  FOCUS.  FDICTION  RASTER 
PURPOSE!  DELETE  INFORMATION  IN  THE  DATA 
DICTIONARY  ON  A  8E6HENT  OF  A  MASTER 
FILE 


-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME  SE8  NAME 
MATCH  FILE  NAME  ^ 

ON  HATCH  CONTINUE 
ON  NOHATCH  REJECT 
MATCH  8E6  NAME 

ON  NONATCH  REJECT 
ON  HATCH  DELETE 

DATA 


MODULE!  DEL3FILE  FOCEXEC 
WRITTEN  BY!  BOB  REPP 
CALLED  BY!  DELFILE  FOCEXEC 
CALLS!  FDICTION  FOCUS,  FDICTION  MASTER 
PURPOSE!  DELETE  INFORMATION  IN  THE  DATA 
DICTIONARY  ON  ONE  FIELD  IN  A  SE8HENT 
OF  A  MASTER  FILE 


-CRTCLEAR 

MODIFY  FILE  FDICTION 

PROMPT  FILE  NAME  SE6  NAME  FIELD  NAME 

HATCH  FILE  NAME 

ON  NORATCH  REJECT 
ON  HATCH  CONTINUE 
MATCH  8E6.NAHE 

ON  NOHATCH  REJECT 
ON  HATCH  CONTINUE 
NATCH  FIELD  NAME 

ON  NONATCH  REJECT 
ON  HATCH  DELETE 

DATA 


MODULE!  CH8FILE  FOCEXEC 
WRITTEN  BY!  BOB  REPP 
CALLED  BY!  HODIFILE  FOCEXEC 
CALLS!  CH6iFILE,CH62FlLE,CH63FILE 
PURPOSE!  UPDATE  FILE  MENU  UNDER 
DICTIONARY  MAINTENANCE 


-SECOND 

-CRTCLEAR 

-TYPE  THIS  IS  THE  UPDATE  MENU  UNDER  DICTIONARY  MAINTENANCE 
-TYPE 


I 


TTCE'RAIRTERANCE'RERD' 


DPDRTE’FTCE'TRFORRRTIOR" « . 


-TYPE  I 
-TYPE  I 
-TYPE  I 
-TYPE  I 
-TYPE  I 
-TYPE  I 
-TYPE  I 
-TYPE  1 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 

-PROMPT  liCHOlCE.  HHAT  IS  YOUR  CHOICE?. 

-IF  liCHOICE  EQ  I  eOTO  CHOIFILI 

ELSE  IF  tiCHOICE  EO  2 

ELSE  IF  tiCHOICE  EQ  3 


UPDATE  MASTER  FILE  INFORMATION 
UPDATE  SE6MENT  INFORMATION  .... 

UPDATE  FIELD  INFORMATION . 

EXIT  . . 


<l> 

<2> 

<3> 

<X> 


-  ELSE  IF  liCHOICE  IS 
ELSE  SOTO  SECOND) 
-CHSIFILE 
EXEC  CHSIFILE 
-RUN 

-CRTCLEAR 
-SOTO  SECOND 
-CH62FILE 
EXEC  CH62FILE 
-RUN 

-CRTCLEAR 
-SOTO  SECOND 
-CH63FILE 
EXEC  CH83FILE 
-RUN 

-CRTCLEAR 
-SOTO  SECOND 
-EXIT 


SOTO  CH62FILE 
SOTO  CH63F1LE 


X'  SOTO  EXIT 


MODULEt  CHSIFILE  FOCEXEC 
NRITTEN  BYi  BOB  REPP 
CALLED  BYi  CHSFILE  FOCEXEC 
CALLSi  FDICTION  FOCUS.  FOICTION  MASTER 
PURPOSEl  UPDATES  MASTER  FILE  INFORMATION 
IN  THE  DATA  DICTIONARY 


-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME 
MATCH  FILE  RAME 

ON  NORATCH  REJECT 

ON  HATCH  PROMPT  FILE  NAME  NUH  SE68  FILE. DESCRIP  MAINTAIN  BY 
ON  HATCH  UPDATE  FILE'TYPE  NUH'SESS  FILE  DESCRIP  MAINTAIN  BY 
DATA  ■  ■ 


MODULEi  CHe2FILE  FOCEXEC 
NRITTEN  BYi  BOB  REPP 
CALLED  BYi  CHSFILE  FOCEXEC 
CALLSi  FDICTION  FOCUS.  FDICTION  MASTER 
PURPOSEl  UPDATES  SESHENT  INFORMATION 
IN  THE  DATA  DICTIONARY 


-CRTCLEAR 

HODIFY  FILE  FOICTION 
PROMPT  FILE  NAME  SEO  NAME 
HATCH  FILE  RAHE 

ON  NATCH  CONTINUE 
ON  NOHATCH  REJECT 
HATCH  SEO  NAME 

ON  NOHATCH  REJECT 

ON  HATCH  PROMPT  CHILD  OF  SEO  TYPE  8E6  DESCRIPT 
ON  HATCH  UPDATE  CHILD'OF  8E6~TYPE  SEB'DESCRIPT 
DATA  "  ■ 

; 


NODULEt  CHS3FILE  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYl  CH6FILE  FOCEXEC 
CALLSi  FDICTION  FOCUS.  FDICTION  MASTER 
PURPOSE!  UPDATES  FIELD  INFORMATION 
IN  THE  DATA  DICTIONARY 


-CRTCLEAR 

MODIFY  FILE  FDICTION 

PROMPT  FILE  NAME  SES  NAME  FIELD  NAME 

HATCH  FILE  RANE 

ON  NORATCH  REJECT 
ON  HATCH  CONTINUE 
HATCH  SE6  NAME 

ON  nOhatch  reject 

ON  HATCH  CONTINUE 
HATCH  FIELD  NAME 

ON  NOHATCH  REJECT 

ON  HATCH  PROMPT  ALTERNATE  FIELD  FORMAT  FIELD  TYPE  KEY  FIELD  DESCRI 
ON  HATCH  UPDATE  ALTERNATE  FIELD'FORHAT  FIELD'TYPE  KEY  FIELD'DESCRI 


HODULEi  EXECHENU  FOCEXEC 
WRITTEN  BYl  BOB  REPP 
CALLED  BYl  HAINHENU  FOCEXEC 
CALLS!  EXECDESC.EXECINFO.SUHEXEC  FOCEXEC 
PURPOSEi  NENU  FOR  ‘CANNED*  DICTIONARY 
REPORTS 


'nATN'NEND' 


■EXEC'HERO' 


-START 

-CRTCLEAR 

-TYPE  THIS  HENU  ALLOWS 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 

-TYPE  . . . 

-TYPE 

-PROHPT  liCHOICE.  WHAT 
-IF  liCHOICE  EQ 

-  ELSE  IF  ItCHOICE  EQ 

-  ELSE  IF  ((CHOICE  EQ 

-  ELSE  IF  ((CHOICE  IS 

-  ELSE  SOTO  START; 

-DESCRIPT 

EXEC  EXECDESC 
-RUN 

-SOTO  START 
-INFO 

EXEC  EXECINFO 
-RUN 

-GOTO  START 
-SUHHARY 
EXEC  SUHEXEC 
-RUN 

-GOTO  START 
-EXIT 


USER  TO  ACCESS  INFORHATION  ON  FOCUS  EXECS 


EXEC  DESCRIPTIONS  .  <1> 

VARIABLE  INFORHATION  .  <2> 

SUHHARY  REPORT  .  <3> 

EXIT  (rvturn  to  oain  otnu).  <X> 


IS  YOUR  CHOICE?. 

1  GOTO  DESCRIPT 

2  GOTO  INFO 

3  GOTO  SUHHARY 
X'  GOTO  EXIT 


HODULEi  EXECINFO  FOCEXEC 
WRITTEN  BYl  BOB  REPP 
CALLED  BYl  EXECHENU  FOCEXEC 
CALLSi  EDICTION  FOCUS.  EDICTION  HASTER 
PURPOSEi  PRINTS  VARIABLE  INFORHATION  BY  EXEC 
FOR  EVERY  EXEC  IN  THE  DATA  DICTIONARY 


-CRTCLEAR 

TABLE  FILE  EDICTION 

PRINT  VAR  NAHE  VAR  FORHAT  VAR  OESCRIPT 

BY  EXEC  NAHE 

FOOTINB‘CENTER 

•TYPE  QUIT  TO  RETURN  TO  HENU* 


MODULEi  EXECDESC  FOCEXEC 

NRITTEN  BYl  BOB  REPP 

CALLED  BYl  EXECMENU  FOCEXEC 

!»#•# 

CALLSi  EDICTION  FOCUS.  EDICTION  MASTER 
PURPOSEi  PRINTS  EXEC  NAME  AND  PURPOSE 

FOR  EVERY  EXEC  IN  THE  DATA  DICTIONARY 

***** 

-CRTCLEAR 

TABLE  FILE  EOICTION 
PRINT  EXEC  NAME  PURPOSE  : 
F00TIN6  CERTER  ^ 

■TYPE  QUIT  TO  RETURN  TO  NENU* 
RUN 


HODULEt  8UHEXEC  FOCEXEC 
NRITTEN  BVi  BOB  REPP 
CALLED  BYl  EXECHENU  FOCEXEC 
CALLSi  EDICTION  FOCUS,  EDICTION  MASTER 
FDICTION  FOCUS.  FDICTION  MASTER 
PURPOSEi  JOINS  FDICTION  AND  EDICTION  IN 
ORDER  TO  PRINT  CALLED  EXECS  AND  MASTER  FILES  USED 
BY  EVERY  EXEC  IN  THE  DATA  DICTIONARY 


-cptclear 

JOIN  FILE  NAME  IN  EDICTION  TO  FILE.NANE  IN  FDICTION  AS  JJOIN 
TABLE  FILE  EDICTION 

PRINT  CALLED  EXEC  FILE  NAME  FILE  DESCRIP 
BY  EXEC  NAME’ 

FOOTINS  CENTER 

■TYPE  QUIT  TO  RETURN  TO  MENU^ 

RUN 


MODULE!  FILEMENU  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYl  MAINMENU  FOCEXEC 
CALLSi  FILDESC.SESINFO.FLDINFO  FOCEXEC 
PURPOSEi  MENU  OF  ■CANNED^  REPORTS  FROM 
THE  DICTIONARY  ON  MASTER  FILES 


-START 

■CRTCLEAR 

-TYPE  THIS  MENU  ALLONS  THE  USER  TO  ACCESS  INFORMATION  ON  FOCUS  FILES 

-TYPE 

■TYPE 

-TYPE 

■TYPE 

■TYPE 

■TYPE  I"  RAIN’RENO . . 

■TYPE  I 

-TYPE  I  I  FTCE'RERO' 

■TYPE 
■TYPE 
■TYPE 
■TYPE 
■TYPE 
■TYPE  1 
■TYPE 
-TYPE 

■TYPE  . 

■TYPE 

■PROMPT  tiCHOICE.  NHAT  IS  YOUR  CHOICE?. 

■IF  ItCHOICE  EQ  1  SOTO  DESCRIPT 


FILE  DESCRIPTIONS  .  <i> 

SE6MENT  INFORMATION  .  <2> 

FIELDNAME  INFORMATION  .  <3> 

SUMMARY  REPORT  .  <4> 

EXIT  (rtturn  to  oiin  oinu).  <X> 
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-  ELSE  IF  liCHOICE  EQ  2  SOTO  SINFQ 

-  ELSE  IF  {(CHOICE  EQ  3  SOTO  FINFO 

-  ELSE  IF  {(CHOICE  EQ  4  SOTO  SUHHARY 

-  ELSE  IF  {(CHOICE  IS  X'  SOTO  EXIT 

-  ELSE  SOTO  START! 

-DESCRIPT 

EXEC  FILDESC 
-RUN 

-CRTCLEAR 
-SOTO  START 
-SINFO 

EXEC  SE6INF0  : 

-RUN  ^ 

-CRTCLEAR 
-SOTO  START 
-FINFO 

EXEC  FLDINFO 
-RUN 

-CRTCLEAR 
-SOTO  START 
-SUHHARY 
EXEC  SUHFILE 
-RUN 

-CRTCLEAR 
-SOTO  START 
-EXIT 


HODULEi  FILDESC  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYt  FILEHENU  FOCEXEC 
CALLSi  FDICTION  FOCUS,  FDICTION  RASTER 
PURPOSE!  PRINTS  FILE  NAHE,  DESCRIPTION.  ETC. 
ON  EVERY  RASTER  FILE  IN  THE  DICTIONARY 


-CRTCLEAR 

TABLE  FILE  FDICTION 

PRINT  FILE  NAHE  FILE.DESCRIP  HAINTAIN  BY  FILE  TYPE  NUH  8E6S 
FOOTING  center 

"TYPE  QUIT  TO  RETURN  TO  HENU" 

RUN 


HODULEt  FLDINFO  FOCEXEC 
NRITTEN  BYt  BOB  REPP 
CALLED  BYt  FILEHENU  FOCEXEC 
CALLSi  FDICTION  FOCUS,  FDICTION  RASTER 
PURPOSEl  PRINTS  FIELD  NAHE,  DESCRIPTION, 
AND  ALIAS  BY  RASTER  FILE  FOR  EVERY 
FIELD  IN  THE  DATA  DICTIONARY 

-CRTCLEAR 

TABLE  FILE  FDICTION 

PRINT  FIELD  NAHE  FIELD  DESCRI  ALTERNATE 
BY  FILE  NAHE 
FOOTING  CENTER 

■TYPE  QUIT  TO  RETURN  TO  HENU" 


HODULEt  SE8INF0  FOCEXEC 
WRITTEN  BYi  BOB  REPP 
CALLED  BYt  FILENENU  FOCEXEC 
CALLSi  FOICTION  FOCUS.  FOICTION  MASTER 
PURPOSE!  PRINT  SE6HENT  NAME,  DESCRIPTION 
AND  PARENT  BY  MASTER  FILE  FOR  EVERY 
SE6MENT  IN  THE  DICTIONARY 


-CRTCLEAR 

TABLE  FILE  FOICTION 

PRINT  SE6  NAME  SE6  DESCRLPT  CHILD  OF  SE6  TYPE 
BY  FILE  NAME  ~  ^ 

F00TIN6  CENTER 

*TYPE  QUIT  TO  RETURN  TO  MENU* 

RUN 


MODULE!  SUMFILE  FOCEXEC 
WRITTEN  BY!  BOB  REPP 
CALLED  BY!  FILEMENU  FOCEXEC 
CALLS!  FOICTION  FOCUS,  FOICTION  MASTER 
PURPOSE!  PRINTS  FILE.  SE6MENT,  AND  FIELD 
INFORMATION  FOR  EVERY  MASTER  FILE  IN 
THE  DATA  DICTIONARY 


-CRTCLEAR 

TABLE  FILE  FOICTION 

PRINT  FIELD  NAME  ALTERNATE  KEY  FIELD  TYPE 
BY  FILE  NAME 
BY  SE6  NAME 
FOOTIN6  CENTER 

•TYPE  QUIT  TO  RETURN  TO  MENU* 


SAMPLE  DICTIONARY  REPORTS 


FILE.NAHE  FILE.DESCRIP 

FDICTION  RASTER  FILE  DICTIONARY 

EOICTION  EXEC  MASTER  DICTIONARY 

ADNISSIO  STUD  AND  COURSES  TAKEN 

AVAIL  CREDIT  HRS  BY  COURSE 

REQ  COURSE  SUBJ  AREAS 


HAINTAIN.BY 

DESI6NER 
R.C.REPP 
NAV  ACAD 
NAV  ACAD 
NPS 


FILE  TYPE 


FOC 

FOC 

FOC 

FOC 

FOC 


NUH.SESS 


3 

4 

2 

1 

1 


FILE.NAHE 

SE6.NAHE 

SE8.DESCRIPT 

CHILD.OF 

SE8.TYPE 

ADNISSIO 

COURSE 

STUD  GRADES  BY  COURSE 

STUDENT 

SI 

STUDENT 

STUD  ID  AND  INFO 

Si 

AVAIL 

DESCRIPT 

CREDIT  HRS  BY  COURSE 

ACOURSE 

SI 

EDICTION 

CALLED 

EXECS  CALLED  BY  AN  EXEC 

EXECS 

Si 

EXECS 

FOCEXEC  DESCRIPTIONS 

EDICTION 

SI 

FILE  NAM 

MASTER  FILES  USED 

EXECS 

SI 

VARIABLE 

VARIABLE  INFORMATION 

EXECS 

SI 

FDICTION 

FIELDS 

INFO  ON  SEGMENT  FIELDS 

SEGMENTS 

SI 

FILES 

INFO  ON  MASTER  FILES 

FDICTION 

SI 

SE6HENTS 

INFO  ON  MASTER  SEGMENTS 

FILES 

SI 

REQ 

DESCRIPT 

COURSE  SUBJ  AREAS 

RCOURSE 

SI 

FILE.NAHE 

ADNISSIO 


AVAIL 

EDICTION 


FDICTION 


REQ 


FIELD  NAME 


COURSE  ID 
LETTER  6RADE 
SEMESTER 
MAJOR 

NATIONALITY 

SEX 

SOC  SEC  NUH 
STUD.ID 
STUD  NAME 
COURSE  ID 
CREDIT  HOURS 
CALLED'EXEC 
EXEC  name 
PURPOSE 
FILE  NAME 
VAR  OESCRIPT 
VAR'FORMAT 
VAR'NAHE 
ALTERNATE 
FIELD  DESCRI 
FIELD'FORMAT 
FIELD’NAHE 
FIELD"TYPE 
KEY  ■ 

FILE  DESCRIP 
FILE'NAHE 
FILE'TYPE 
MAINTAIN  BY 
NUH  SE6S 
CHICD  OF 
SE6  DESCRIPT 
SE6  NAME 
SE6  TYPE 
COURSE  ID 
SUBJ  AREA 


FIELD.DESCRI 

ALTERNATE 

COURSE  ID  NUMBER 

CIO 

FINAL  GRADE  ASSIGNED 

LG 

WHEN  TAKEN  <SEH/YEAR) 

WHEN 

AREA  OF  DEGREE 

HAJ 

COUNTRY  OF  ORIGIN 

RACE 

SEX 

SEX 

SOCIAL  SECURITY  NO. 

SSN 

STUDENT  ID 

SID 

STUDENT  NAME 

SN 

COURSE  ID  NUMBER 

CID 

0.0  TO  4.0  COURSE  CREDIT 

CHRS 

NAME  OF  CALLED  EXEC 

CE 

NAME  OF  FOCEXEC 

EN 

PURPOSE  OF  FOCEXEC 

DOES 

FOCUS  MASTER  FILE  DESCRIP 

FLN 

DESCRIPTION  OF  VARIABLE 

VOES 

ALLONABLE  VARIABLE  FORMAT 

VFMT 

VARIABLES  USED  IN  FOCEXEC 

VN 

ALIAS 

ALT 

INFO  ON  SEGMENT  FIELDS 

FDOE 

TYPE  ti  AMOUNT  OF  DATA 

FFHT 

NAME  OF  FIELD 

FDN 

I  MEANS  INDEXED 

FDTP 

Y  MEANS  KEY  FIELD 

KEY 

DESCRIPTION  OF  MASTER 

FDES 

NAME  OF  FOCUS  MASTER  FILE 

FLN 

TYPE  OF  MASTER  FILE 

FTYP 

ACTIVITY  RESPONSIBLE 

FNAN 

NUMBER  OF  SEGMENTS 

NS 

PARENT  OF  SEGMENT 

SPAR 

INFO  ON  MASTER  SEGMENTS 

SDES 

NAME  OF  MASTER  SEGMENT 

SE8N 

SEGMENT  KEY  fc  ORDER  INFO 

STYP 

COURSE  ID  NUMBER 

CID 

SUBJECT  AREA  OF  COURSE 

SA 
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FILE.NAHE  SEB.NAHE  FIELO.NAHE  ALTERNATE  KEY  FIELD.TYPE 


A0NIS8I0  COURSE 


STUDENT 


AVAIL  DESCRIPT 

EDICTION  CALLED 
EXECS 

FILE  NAN 
VARIABLE 


FDICTION  FIELDS 


FILES 


SE6HENTS 


DESCRIPT 


EXEC.NANE  PURPOSE 

NAINNENU  DATA  DICTIONARY  CHOICES 

FILEHENU  FOCUS  FILE  INFO  MENU 

EXECNENU  FOCUS  EXECS  INFO  HENU 

HANTHENU  NAINTENANCE  HENU 

HODIEXEC  HODIFY  EXEC  INFO  HENU 

CH6EXEC  UPDATE  EXEC  INFO  HENU 

CHSIEXEC  UPDATES  VARIABLE  INFO 

DELEXEC  DELETE  EXEC  INFO  HENU 

OELIEXEC  DELETE  INFO  ON  AN  EXEC 

DEL2EXEC  DELETE  INFO  ON  A  VARIABLE 
DEL3EXEC  DELETE  INFO  ON  A  FILE 

DEL4EXEC  DELETE  INFO  ON  EXEC 

AODEXEC  ADD  EXEC  INFORNATION 

ADDIEXEC  ADD  EXEC  NAHE8 

ADD2EXEC  ADD  VARIABLE  INFO 

ADD3EXEC  ADD  HASTEN  FILE  INFO 

AD04EXEC  ADD  CALLED  EXEC  INFO 

CH62EXEC  UPDATES  EXEC  PURPOSE 

PROJHENU  CALLS  PR06RAH  OR  DICTION 
CALCOPR  CALCULATES  OPR  BY  STUDENT 
SUBJSUH  TABLES  BRADES  BY  SUBJ 


COURSE  ID 
LETTER'SRADE 
SEHESTER 
HAJOR 

NATIONALITY 

SEX 

SOC  SEC  NUN 
STUD  ID~ 

STUD  NAHE 
COWSE  ID 
CREDIT'HOURS 
CALLED'EXEC 
EXEC  NAHE 
PURPOSE 
FILE  NAHE 
VAR  DESCRIPT 
VAR'FORHAT 
VAR'NAHE 
ALTERNATE 
FIELD  DESCRI 
FIELD'FORHAT 
FIELD'NAHE 
FIELD'TYPE 
KEY  ■ 

FILE  DESCRIP 

FILE'NAHE 

FILE'TYPE 

hainTain  by 

NUH  SE6S~ 
CHICD  OF 
SE6  DESCRIPT 
SE6  NAHE 
SE6"TYPE 
C0UR8E.ID 
SUBJ  AREA 
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APPENDIX  B 


TRANSCRIPT  SUMMARY  APPLICATION  SOURCE  CODE 


NOOULEt  PROJHENU  FOCEXEC 
WRITTEN  BYi  BOB  REPP 
CRlLED  BY: 

CALLSt  CALCQPR.  SUBJSUN,  HAINHENU  FOCEXEC 
PURPOSE.  HAIN  PROJECT  HENU 


********************************************************************* 

SET  HS6-0FF 

-CRTCLEAR 

-BEGIN 

-CRTCLEAR 


r"PR03ECT‘HER0 . . I . 

I  STUDENT  TRANSCRIPT  SUNHARY  .  <1>  I 

I  DATA  DICTIONARY  .  <2>  I 

I  OUIT  .  <Q>  I 

t  I 

I  I 

t  I 

I  » 

I  I 


-PRONPT  tcSELECT.  WHAT  IS  YOUR  CHOICE?. 
-IF  liSELECT  EB  1  GOTO  CALCQPR 

ELSE  IF  IcSELECT  EQ  2  GOTO  NAINHENU 
ELSE  IF  liSELECT  IS  B'  SOTO  EXIT 
ELSE  GOTO  BEGINi 
-CALCQPR 
EXEC  CALCQPR 
-RUN 

EXEC  SUBJSUN 
-RUN 

-CRTCLEAR 
-SOTO  BEGIN 
-NAINHENU 
EXEC  NAINHENU 
-RUN 

-CRTCLEAR 
-GOTO  BEGIN 


-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 


##•*## *««*####»** #*#**«•# ft# 

MOOULEi  CALCBPR  FOCEXEC 
WRITTEN  BVt  BOB  REPP 
CALLED  BYi  PROJNENU  FOCEXEC 
CALLS:  ADHISSIO  FOCUS,  AVAIL  FOCUS 

AVAIL  RASTER.  ADHISSIO  RASTER 
PURPOSE:  JOINS  FILES  AND  CALCULATES  QPR 
FOR  EACH  STUDENT  BASED  ON  ALL  COURSES  TAKEN  EXCEPT  THOSE 
WITH  A  GRADE  OF  "V 

*«t«*«*«*«f*«*««f «*«**•««*«*•****#**• t*t***t**********ttt*t*t«tt*t*« 

“CRTCLEAR 

JOIN  CID  IN  ADHISSIO  TO  QID  IN  AVAIL  AS  AJOIN 
DEFINE  FILE  ADHISSIO 
N6RADE/F3. 1>IF  LG  EQ  'A'  THEN  4.0 
ELSE  IF  LG  EQ  'B'  THEN  3.0 
ELSE  IF  LG  EQ  C'  THEN  2.0 
ELSE  IF  LG  EQ  '0'  THEN  1.0 
ELSE  O.Oj 

P0INTS/F6. 1-N6RA0E«CHRS; 

END 

TABLE  FILE  ADHISSIO 

SUH  POINTS  NOPRINT  CHRS  NOPRINT 

COHPUTE  QPR/F4.1»P0INTS/CHRS: 

BY  SID  BY  STUD  NAHE  BY  SSN  BY  HAJOR 
IF  LG  OHITS  'V' 

END 


«*****•*«#•«*«•#***««**«««*«*««•«*«§ t •***#«*««#*«*«»««*#««##**#«#«** 

HODULEi  SUBJSUH  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  PROJHENU  FOCEXEC 
CALLS:AOHISSIO  FOCUS, ADHISSIO  RASTER 
REQ  FOCUS,  RED  RASTER 

PURPOSE:  JOINS  ADHISSIO  AND  REQ  AND  PRINTS 
THE  NUHBER  OF  COURSES  TAKEN  BY  SUBJECT  AREA  ACROSS  GRADES 
******************************************************************** 
JOIN  CID  IN  ADHISSIO  TO  CIO  IN  REQ  AS  BJOIN 
TABLE  FILE  ADHISSIO 
FOOTING  CENTER 

“TYPE  QUIT  TO  RETURN  TO  HENU“ 

COUNT  CID  ACROSS  LG 
BY  SID  BY  SA 
ON  SID  PAGE-BREAK 
RUN 


TRANSCRIPT  SUMMARY  APPLICATION  OUTPUT 


STUD_ID 

STUD_NAME 

SOC_SEC_NUM 

MAJOR 

QPR 

840007 

ABBOT  LOHN  F 

423788586 

ESE 

3.7 

840019 

ABELL  DAVID  GROS 

512727258 

SAS 

2.4 

840024 

ABRAMSON  ALAN  J 

037367483 

SPH 

3.0 

STUD_ID 

SUBJ_AREA 

LETTER 

A 

GRADE 

B 

C 

D 

V 

840007 

MATH  C 

0 

1 

0 

0 

0 

MATH  PO 

1 

0 

0 

0 

0 

MATH~PR 

1 

0 

0 

0 

1 

STATS 

0 

0 

1 

0 

0 

STUD^ID 

SUB J_ ARE A 

LETTER 

A 

GRADE 

B 

C 

D 

V 

840019 

CHEM 

1 

0 

0 

0 

0 

MATH  C 

0 

0 

1 

0 

0 

MATH  PQ 

0 

0 

1 

0 

0 

PHY  CD 

0 

0 

1 

0 

0 

PHY  UD 

0 

0 

0 

1 

0 

STUD_ID 

SUB J_ ARE A 

'LETTER 

A 

.GRADE 

B 

C 

D 

V 

840024 

A  M  ENG 

0 

1 

0 

0 

0 

ECECT  E 

0 

1 

0 

0 

0 

MATH  PR 

0 

0 

0 

0 

1 

QPHYSCI 

0 

1 

0 

0 

0 

OTH  ENG 

0 

1 

0 

0 

0 
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